Re: [PATCH] combine: Try harder to form zero_extends [PR106594]

[Jakub Jelinek <jakub@redhat.com>]

On Mon, Mar 06, 2023 at 03:08:00PM +0000, Richard Sandiford via Gcc-patches wrote:
> Segher Boessenkool <segher@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 ?

	Jakub