https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to ktkachov from comment #3) > (In reply to Richard Biener from comment #2) > > The regression is probably rtl-optimization/target specific since we never > > had this kind of pattern detected on the tree/GIMPLE level and there's no > > builtin or IFN for this shuffling on u32. > > FWIW a colleague reported that he bisected the failure to > g:98e30e515f184bd63196d4d500a682fbfeb9635e though I haven't tried it myself. There's a slight difference in before/after since GENERIC folding only applied the (X & C2) << C1 into (X << C1) & (C2 << C1) transform when the new BIT_AND "simplified": - tem = fold_binary_loc (loc, BIT_AND_EXPR, type, shift, mask); - if (tem) - return tem; The transform was added in r0-84712-g22164c3db76535 for some rotate patterns, tested by gcc.dg/fold-rotate-1.c, the pattern was meanwhile extended to cover other bit operations as well. > We do have patterns for these in aarch64 and arm, but combine would need to > match about 5 insns to get there and that's beyond its current limit of 4 maybe some helper patterns no longer catch the differently canonicalized forms?
