[RFA][PATCH][tree-optimization/78496] 01/03 Do not lose range information from earlier VRP passes
Jeff Law
law@redhat.com
Mon Dec 4 15:14:00 GMT 2017
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
More information about the Gcc-patches
mailing list