This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #4)
> (In reply to Richard Biener from comment #1)
> > Confirmed.  Sth like
> > 
> >  (simplify
> >   (ne (bit_and (lshift integer_onep @0) integer_onep) integer_zerop)
> >   (eq @0 { build_zero_cst (TREE_TYPE (@0)); })
> > 
> > with eventually also covering if ((1 & (1<< n)) == 0) -> if (n & 1 == 0)
> > 
> > You can extend this to cover the other cases you mention.
> 
> I thought you might suggest something like this. :)

Note that this transformation doesn't work.

> While the transform for the if (...) is probably going to be beneficial for
> all the targets, I'm not so sure about the 'return ((1 << 1) & (1 << n));'
> variant, though.  On some targets a shift+and might be cheaper than
> cmp+cstore.  Is there any way to get that information during tree
> optimization?  If not, it might be better to do that transformation on the
> RTL.

I don't think so.  I tried to come up with a more general transformation that
would simplify ((CST << n) & CST) != 0, but I haven't found anything yet.  So
maybe just this?
((1 << n) & 1) != 0 -> n == 0
((1 << n) & 1) == 0 -> n != 0


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]