Re: [RFA][PATCH][tree-optimization/78496] 01/03 Do not lose range information from earlier VRP passes

[Jeff Law <law@redhat.com>]

On 12/04/2017 01:11 AM, Jakub Jelinek wrote:
> On Sun, Dec 03, 2017 at 10:55:27PM -0700, Jeff Law wrote:
>> As we touched on in IRC, the EVRP analyzer was doing something stupid
>> which caused it to not merge in existing range information under certain
>> circumstances.
>>
>> Consider this fragment:
>>
>>   x_1 = foo ()
>>   if (x_1 > 2)
>>     __builtin_unreachable ();
>>   if (x_1 < 0)
>>     __builtin_unreachable ();
> 
> Note that for say:
>   x_1 = foo ();
>   bar (x_1);
>   if (x_1 > 2)
>     __builtin_unreachable ();
>   if (x_1 < 0)
>     __builtin_unreachable ();
>   ...
>   further uses of x_1
> we can't do that anymore (at least, can't remember it in
> SSA_NAME_RANGE_INFO), as bar could not return/could loop etc.
Right.  Anything reflected into SSA_NAME_RANGE_INFO has to be globally
true.  With the call to bar the transformation can't safely be applied.

  Ditto with
> any other code in between foo and the unreachable asserts if it doesn't
> guarantee that we'll always reach the comparisons after the x_1 setter.
> Even
>   x_1 = foo ();
>   bar ();
>   if (x_1 > 2)
>     __builtin_unreachable ();
>   if (x_1 < 0)
>     __builtin_unreachable ();
> looks unclean, if bar doesn't return, then we'd just need to hope we don't
> add further uses of x_1 in between foo and bar.  Some optimizations do stuff
> like that, consider foo being a pass-through function.
This one is less clear.  But I don't think we should be trying to
optimize this case anyway -- too little to be gained and too close to
doing something unexpected.

jeff