Only simplify TRUNCATE to SUBREG on TRULY_NOOP_TRUNCATION targets

As recently remarked by Jeff Law, SUBREGs are the "forever chemicals"
of GCC's RTL; once created they persist in the environment.  The problem,
according to the comment on lines 5428-5438 of combine.c is that
non-tieable SUBREGs interfere with reload/register allocation, so
combine often doesn't touch/clean-up instructions containing a SUBREG.

This is the first and simplest of two patches to tackle that problem,
by teaching combine to avoid converting explicit TRUNCATEs into
SUBREGs that it can't handle.

Consider the following (hypothetical) sequence of instructions on
a STORE_FLAG_VALUE=1 target, which stores a zero or one in an SI
register, then uselessly truncates to QImode, then extends it again.

(set (reg:SI 27) (ne:SI (reg:BI 28) (const_int 0)))
(set (reg:QI 26) (truncate:QI (reg:SI 27)))
(set (reg:SI 0) (zero_extend:SI (reg:QI 26)))

which ideally (i.e. with this patch) combine would simplify to:
(set (reg:SI 0) (ne:SI (reg:BI 28) (const_int 0)))

Alas currently, during combine the middle TRUNCATE is converted into
a lowpart SUBREG, which subst then turns into (clobber (const_int 0)),
abandoning the attempted combination, that then never reaches recog.

This patch has been tested on x86_64-pc-linux-gnu with "make bootstrap"
and "make -k check" with no new failures, and also on nvptx-none.
But it only affects !TRULY_NOOP_TRUNCATION targets, and the motivating
example above is derived from the behaviour of backend patches not yet
in the tree [nvptx is currently a STORE_FLAG_VALUE=-1 target].

Ok for mainline?


2021-08-27  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
	* combine.c (combine_simplify_rtx): Avoid converting an explicit
	TRUNCATE into a lowpart SUBREG on !TRULY_NOOP_TRUNCATION targets.
	* simplify-rtx.c (simplify_unary_operation_1): Likewise.

Roger
--

On 8/27/2021 3:57 PM, Roger Sayle wrote:
> As recently remarked by Jeff Law, SUBREGs are the "forever chemicals"
> of GCC's RTL; once created they persist in the environment.  The problem,
> according to the comment on lines 5428-5438 of combine.c is that
> non-tieable SUBREGs interfere with reload/register allocation, so
> combine often doesn't touch/clean-up instructions containing a SUBREG.
Forever chemicals.  I like that term.   There's other places that have 
related hackery.   cse.c in particular.

> Alas currently, during combine the middle TRUNCATE is converted into
> a lowpart SUBREG, which subst then turns into (clobber (const_int 0)),
> abandoning the attempted combination, that then never reaches recog.
>
> This patch has been tested on x86_64-pc-linux-gnu with "make bootstrap"
> and "make -k check" with no new failures, and also on nvptx-none.
> But it only affects !TRULY_NOOP_TRUNCATION targets, and the motivating
> example above is derived from the behaviour of backend patches not yet
> in the tree [nvptx is currently a STORE_FLAG_VALUE=-1 target].
It's unfortunate that STORE_FLAG_VALUE is static.   Many ports could 
store a variety of useful value as part of the scc insn rather than have 
the scc produce a value, then we manipulate it with shifts, negation, 
multiplication, whatever to get the value we ultimately wanted.  We've 
run into this internally repeatedly on tachyum's port.  They might be 
better modeled as an if-then-else.  But I digress....



> Ok for mainline?
>
>
> 2021-08-27  Roger Sayle  <roger@nextmovesoftware.com>
>
> gcc/ChangeLog
> 	* combine.c (combine_simplify_rtx): Avoid converting an explicit
> 	TRUNCATE into a lowpart SUBREG on !TRULY_NOOP_TRUNCATION targets.
> 	* simplify-rtx.c (simplify_unary_operation_1): Likewise.
OK
jeff

Hi!

On Fri, Aug 27, 2021 at 05:20:22PM -0600, Jeff Law via Gcc-patches wrote:
> On 8/27/2021 3:57 PM, Roger Sayle wrote:
> >As recently remarked by Jeff Law, SUBREGs are the "forever chemicals"
> >of GCC's RTL; once created they persist in the environment.  The problem,
> >according to the comment on lines 5428-5438 of combine.c is that
> >non-tieable SUBREGs interfere with reload/register allocation, so
> >combine often doesn't touch/clean-up instructions containing a SUBREG.
> Forever chemicals.  I like that term.

It is a very clever name in its original meaning.  Not only are PFAS and
the like not degraded in the environment, but that is because the F-C
bond is so strong...  the "Forever-Chemical" bond.  Chemists make even
worse puns than compiler developers :-)

SUBREGs are like perfluoralkyls in more ways: they have huge problems,
but there is no real replacement for them either.

> >Alas currently, during combine the middle TRUNCATE is converted into
> >a lowpart SUBREG, which subst then turns into (clobber (const_int 0)),
> >abandoning the attempted combination, that then never reaches recog.

Yeah, combine notices it can optimise away the TRUNCATE (a SUBREG is
free, is just a reinterpret_cast thingy, no machine operation).  With
this code disabled (for !TRULY_NOOP_TRUNCATION_MODES_P) you will get
less optimised code.

> >But it only affects !TRULY_NOOP_TRUNCATION targets, and the motivating
> >example above is derived from the behaviour of backend patches not yet
> >in the tree [nvptx is currently a STORE_FLAG_VALUE=-1 target].

Should the TARGET_TRULY_NOOP_TRUNCATION documentation be updated now?
In particular the part that talks about TARGET_MODES_TIEABLE_P.


Segher