On Tue, 9 Jun 2015, Marc Glisse wrote: > On Tue, 9 Jun 2015, Richard Biener wrote: > > > On Tue, 9 Jun 2015, Richard Biener wrote: > > > > > On Tue, 9 Jun 2015, Marc Glisse wrote: > > > > > > > On Tue, 9 Jun 2015, Richard Biener wrote: > > > > > > > > > > Tweaking it so that (6<<X)==0 becomes X>=31 for TYPE_OVERFLOW_WRAPS > > > > > > and > > > > > > false for TYPE_OVERFLOW_UNDEFINED is probably more controversial. > > > > > > > > > > Hm, yes. I think signed overflow != shift amount overflow, so testing > > > > > the > > > > > overflow macros for this isn't valid. > > > > > > > > Would it be ok to always turn it to X>=31 then? (the value 31 is > > > > conveniently > > > > already computed in 'cand') > > > > > > I think so. > > > > Or even ((unsigned)X - 31) < 1 (I probably got that wrong) to properly > > say X>=29 && X<32, that is, preserve the implicit upper bound on X > > we have because it is used in a shift. > > I don't understand in what sense this preserves the upper bound. I would > understand storing a range for X (when it is an SSA_NAME, and it would require > a lot of care not to propagate backwards too far), or more simply introducing > if(X>=32) __builtin_unreachable();. But you seem to be talking about > generating more complicated code so that if someone checks (6<<123)==0 it > returns false?
Well, I'm mixing simplifying the computation and preserving extra info we got from the complex computation. So yes, you are right. Richard.
