Jakub Jelinek <ja...@redhat.com> writes: > On Mon, Mar 06, 2023 at 03:08:00PM +0000, Richard Sandiford via Gcc-patches > wrote: >> Segher Boessenkool <seg...@kernel.crashing.org> writes: >> > On Mon, Mar 06, 2023 at 12:47:06PM +0000, Richard Sandiford wrote: >> >> How about the patch below? >> > >> > What about it? What would make it any better than the previous? >> >> It does what Jeff suggested in the quoted message: work within the existing >> extract/make_compound_operation scheme rather than try to opt out of it. > > That still feels like it could be risky in stage4, affecting various other > FEs which would be expecting ANDs in their patterns instead of *_EXTEND, no? > So, at least we'd need something like Segher ran to test it on various > targets on Linux kernel (but would be really nice to get also i?86/x86_64). > > If it were on the aarch64 side just one pattern, I'd suggest a pre-reload > splitter, but unfortunately the sign extends (and zero extends?) are handled > in legitimate address hook. Also, I see nonzero_bits only called in > rs6000's combine splitter and s390'x canonicalize_comparison target hook, > nowhere else in the backends, so I think using it outside of the combiner > isn't desirable. > > Could we have a target hook to canonicalize memory addresses for combiner, > like we have that targetm.canonicalize_comparison ?
I don't think a hook makes sense as a long-term design decision. The canonicalisation we're doing here isn't logically AArch64-specific, and in general, the less variation in RTL rules between targets, the better. But if you mean adding target control as a GCC 13 hack, to avoid any effect on other targets, then TBH, I'd prefer just sticking it in an #ifdef GCC_AARCH64_H :-) That makes it 100% clear that it's a temporary hack to restrict the target impact rather than something based on fundamentals. We can then revisit for GCC 14. Thanks, Richard
