https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925
--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Then people realized that there was a problem if the SUBREGs were spilled onto
the stack at some point, hence an additional test on LOAD_EXTEND_OP:
r8787 | wilson | 1995-01-21 03:23:10 +0100 (Sat, 21 Jan 1995) | 3 lines
(num_sign_bit_copies): Can handle paradoxical subreg only
if LOAD_EXTEND_OP is defined to SIGN_EXTEND.
r19928 | amylaar | 1998-05-21 13:35:10 +0200 (Thu, 21 May 1998) | 3 lines
* combine.c (nonzero_bits): For paradoxical subregs, take
LOAD_EXTENDED_OP into account.
Then, in order to fix PR c/2454 on some platform, the mechanism was killed for
the first time without much ado:
r55386 | sayle | 2002-07-11 03:23:07 +0200 (Thu, 11 Jul 2002) | 5 lines
PR c/2454
* combine.c (nonzero_bits): LOAD_EXTEND_OP should only apply
to SUBREGs of MEMs. (num_sign_bit_copies): Likewise.
Now the mechanism was quite powerful on RISC architectures whose loads are
implicitly extended via LOAD_EXTEND_OP and the infrastructure was still present
in the compiler so I decided to revive it after stumbling for the 47th time on
a trivially redundant extension in some SPARC assembly. This initially
required only a few adjustments and fixes left and right outside the combiner
but it now appears that they are major issues within the combiner itself which
cannot be solved in a satisfactory way.
