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

[Segher Boessenkool <segher@kernel.crashing.org>]

On Mon, Mar 06, 2023 at 05:18:50PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 06, 2023 at 03:08:00PM +0000, Richard Sandiford via Gcc-patches wrote:
> 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).

It is running.  Still without x86 though, but I'll add that later
hopefully, also for the previous runs.

> 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.

nonzero_bits cannot be used in insn conditions.  This is a well-known
long-standing problem.

The problem is that it can give different output in the passes after
combine than it does in combine itself, since combine does more thorough
analysis.  This than causes insns generated in combine to no longer be
recognised later -> kaboom, ICE.

> Could we have a target hook to canonicalize memory addresses for combiner,
> like we have that targetm.canonicalize_comparison ?

If it makes sense, sure.  And it is implemented in a sensible spot.  It
has to stay maintainable :-)

Looking foreward to a patch,


Segher