This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch tree-optimization]: [3 of 3]: Boolify compares & more
2011/7/8 Richard Guenther <richard.guenther@gmail.com>:
> On Thu, Jul 7, 2011 at 6:28 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>> 2011/7/7 Paolo Bonzini <bonzini@gnu.org>:
>>> On 07/07/2011 06:07 PM, Kai Tietz wrote:
>>>>
>>>> + ?/* We redo folding here one time for allowing to inspect more
>>>> + ? ? complex reductions. ?*/
>>>> + ?substitute_and_fold (op_with_constant_singleton_value_range,
>>>> + ? ? ? ? ? ? ? ? ? ? ?vrp_fold_stmt, false);
>>>> + ?/* We need to mark this second pass to avoid re-entering of same
>>>> + ? ? edges for switch statments. ?*/
>>>> + ?in_second_pass = true;
>>>> ? ?substitute_and_fold (op_with_constant_singleton_value_range,
>>>> ? ? ? ? ? ? ? ? ? ? ? vrp_fold_stmt, false);
>>>> + ?in_second_pass = false;
>>>
>>> This needs a much better explanation.
>>>
>>> Paolo
>>
>> Well, I can work on a better comment. ?The complex reduction I mean
>> here are cases like
>>
>> int x;
>> int y;
>> _Bool D1;
>> _Bool D2;
>> _Bool D3;
>> int R;
>>
>> D1 = x[0..1] != 0;
>> D2 = y[0..1] != 0;
>> D3 = D1 & D2
>> R = (int) D3
>>
>> (testcase is already present. See tree-ssa/vrp47.c).
>>
>> As VRP in first pass produces (and replaces) to:
>>
>> D1 = (_Bool) x[0..1];
>> D2 = (_Bool) y[0..1];
>> D3 = D1 & D2
>> R = (int) D3
>>
>> Just in the second pass the reduction
>>
>> R = x[0..1] & y[0..1]
>
> So why wouldn't that happen during the first pass? ?The first
> pass could change the IL to
The issue is that substitute_and_fold runs within BBs statements
folding from last to first. So most simplifications are done too late
to recognize dependent one. Maybe it would be another way here to have
a flag for substitute_and_fold to indicate that folding pass shall run
first -> last or last->first?
> ?D1 = x[0..1] != 0;
> ?D2 = y[0..1] != 0;
> ?D3 = D1 & D2;
> ?R = x & y;
>
> if D3 only has a single use.
Well, to change type of an SSA-name, if it has single-use might be
another way here. To have the ability to enter new temp-registers
would be better and avoids the dependency of single use, but well,
range tables don't support that now.