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