On Tue, Jan 13, 2026 at 12:20 PM Jeffrey Law <[email protected]> wrote: > > > > On 1/13/2026 10:39 AM, Andrew Pinski wrote: > > This is a small reassociation for `a*bool & b` into `(a & b) * bool` > > checking if > > `a & b` simplifies. Since it could be the case `b` is `~a` or `a` or > > something > > else that might simplify when anding with `a`. > > > > Note this fixes a regression for aarch64 where the cost of a multiply vs > > `&-` changed > > in GCC 14 and can no longer optimize some cases at the RTL level. > > > > Bootstrapped and tested on x86_64-linux-gnu. > > > > PR tree-optimization/119402 > > gcc/ChangeLog: > > > > * match.pd (`(a*zero_one_valued_p) & b`): New pattern. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.dg/tree-ssa/bitops-14.c: New test. > > * gcc.dg/tree-ssa/bitops-15.c: New test. > Last I looked we didn't have scalar support for a & ~b as a named > pattern, but it seems like that's another good reason (at some point) > to trying and bring the logical terms together in general since multiple > ISAs have a full complement (pun intended) of logical-with-complement > style operations.
GCC does have an internal function for `a&~b` though and it works with the scalar modes with the optabs. That is one thing I made sure worked as I had to rename the optab to andn from andc (due to csi being the complex si mode and being matched). https://inbox.sourceware.org/gcc-patches/[email protected]/ At the time I was looking into use the internal function but this was before fold_before_rtl_expansion_p/PROP_last_full_fold was around. This is something I will be looking into finishing up during stage 1 though. Thanks, Andrew > > And more generally, there are guidelines (from an ancient HP paper) on > reassociation and this would seem to generally fit. An AND operation > would largely be similar to PLUS and would have a different priority > than MULT. So when you rewrite in the way you're doing you'll generally > tend to improve CSE, LICM and IVopts. It's been eons since I studied > that work, so don't ask for more details :-) > > Anyway, OK for the trunk. Thanks. > > jeff > >
