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