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