On Mon, Nov 20, 2017 at 3:10 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Mon, 20 Nov 2017, Richard Biener wrote: > >>> I had to adapt one testcase where for VR_VARYING | [1, 1] we used to >>> produce >>> ~[0, 0] and now produce [-INT_MAX, INT_MAX]. I am surprised at how late >>> the >>> transformation now happens (only after removing __builtin_unreachable, in >>> forwprop3, while trunk currently has it in evrp IIRC), but I didn't >>> investigate, doesn't seem like the right time with all the VRP changes >>> going >>> on. >> >> >> Interesting - can you open a bugreport so we don't forget? I suspect it's >> the effect of zero_nonzero_bits_from_vr handling VARYING and [INT_MIN, >> INT_MAX] >> differently rippling down. At some point in time I wanted to get rid of >> VARYING >> in favor of [INT_MIN, INT_MAX] ... > > > I filed PR 83072 about missing the optimization in evrp, but now I am not > sure if that's what you wanted in the PR or if you wanted one about chosing > between ~[0, 0] and [-INT_MAX, INT_MAX] for VR_VARYING | [1, 1]...
Yes, the one choosing between these two. The EVRP missed optimization is of course also useful to track. Richard. > -- > Marc Glisse