https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #3) > We are still in stage3, why not do it now? > I don't see the point in handling &/== and |/!= in the same simplification > when you do something completely different for those. > Why not e.g. > (simplify > (bit_and:c > (eq (bit_and @0 INTEGER_CST@1) @1) > (eq (bit_and @0 INTEGER_CST@2) @2)) > (eq (bit_and @0 (bit_ior @1 @2)) (bit_ior @1 @2))) > and something with integer_onep@2 for the bit_ior/ne? > Also, why do you treat &/== and |/!= differently? > I mean, if ((x&7)==7)&((x&13)==13) can be optimized into (x&15)==15, why > can't you optimize ((x&7)!=7)|((x&13)!=13) into (x&15)!=15? integer_onep should have been integer_zerop :) I had a few typos anyways. I have to think this through really; that is why not for stage3; also I am working on other things at this point. This was a side part of the what was I working on doing. Also we change (x&7)==7 to (x&7)!=0 before hand which means we need to match that also.
