On Thu, 10 Nov 2016, Richard Biener wrote: > On November 10, 2016 7:39:57 PM GMT+01:00, Marc Glisse <marc.gli...@inria.fr> > wrote: > >On Thu, 10 Nov 2016, Richard Biener wrote: > > > >> The following fixes PR71762 via reverting the transforms of > >> ~X & Y to X < Y and similar because when the bools they apply to > >> are expanded to RTL undefined values are not reliably zero-extended > >> and thus the transform is invalid. Ensuring the zero-extension > >> is too costly IMHO and the proper fix is to move the transform > >> to RTL where we can check known-zero-bits to validate validity > >> or to fix GIMPLE not not have operations on types not matching their > >mode > >> in precision. > > > >Can you explain why this particular transformation is special? We have > >a > >number of other optimizations that take advantage of the fact that bool > >is > >in [0, 1], even without looking at VRP, say for instance x != 0 -> x. > >Are > >we supposed to remove all of them? > > No. But UNDEFINED & 0 is well-defined > Even if precision ends up being bigger. Undefined != 0 is never well-defined.
Now applied to trunk. Richard.
