[patch tree-optimization]: [3 of 3]: Boolify compares & more

Kai Tietz ktietz70@googlemail.com
Fri Jul 8 14:40:00 GMT 2011


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
>
>  D1 = x[0..1] != 0;
>  D2 = y[0..1] != 0;
>  D3 = D1 & D2;
>  R = x & y;
>
> if D3 only has a single use.
No, as D3 would need a type change, and this isn't possible.  If it
wasn't absolutely clear, this patch to VRP is necessary after patch 2,
as here D1, D2, and D3 have bool-type, and just R is of type int.

>> can happen.  In general it is sad that VRP can't insert during pass
>> new statements right now.  This would cause issues in range-tables,
>> which aren't designed for insertations.  As otherwise, we could do
>> also simplify things like
>>
>> D1 = x[0..1] != 0;
>> D2 = y[0..1] == 0;
>> D3 = D1 & D2
>> R = (int) D3
>>
>> to
>> R = x[0..1] & (y[0..1] ^ 1)
>
> Why that ^ 1?  And why does that confuse the range tables
> if you re-use R?
Because we would need to insert a new statement and this isn't allowed
in VRP. See the comments in VRP and substitute_and_fold.  VRP
disallows to remove statements or to insert new ones.

>> Regards,
>> Kai



More information about the Gcc-patches mailing list