On 6/6/19 1:31 AM, Richard Biener wrote: [ Big snip ] > >> I was primarily concerned with the ones in the evrp simplification >> engine which are easy to fix in-place. Looking at gimple-fold.c I agree >> we do need to address the walking problem. >> >> I'm not sure we can drop to varying though -- my first twiddle of this >> did precisely that, but that'll likely regress vrp47 where we know the >> resultant range after simplification is just [0,1]. > > Of course we do not need to drop the original LHS to VARYING, only > the defs we didn't already visit. I was referring to the newly created def. There's a case (seen in vrp47 IIRC) where the new temporary has a known range [0,1] and we need to know that for subsequent simplifications. But if your change passes regression testing, then we're still picking that up properly.
> >> Ideally we wouldn't have the simplifiers creating new names or we'd have >> a more robust mechanism for identifying when we've created a new name >> and doing the right thing. I suspect whatever we do here right now is >> going to be a bandaid and as long as we keep creating new names in the >> simplifier we're likely going to be coming back and applying more bandaids. > > Re-visiting the stmts would be possible if we'd split registering ranges > derived > from uses of a stmt from those of defs (IIRC I had incomplete patches to do > that > when trying to derive X != 0 from Y / X because otherwise we miscompile > stuff). > > Meanwhile I have bootstrapped / tested the following which does the VARYING > thing. > > Applied to trunk. I think we need to backport this since this is a latent > wrong-code issue. We can see to improve things on the trunk incrementally. Works for me. jeff
