Re: Analysis of high priority PR c/2454

[Jeff Law <law at porcupine dot slc dot redhat dot com>]

In message <Pine.LNX.4.33.0207010811380.22390-100000@www.eyesopen.com>, Roger S
ayle writes:
 >
 >> Thanks for the pointer.  Indeed, thanks to your analysis, the
 >> PA-RISC problem is caused by simplify_shift_const reducing
 >>
 >>     (lshiftrt:SI (ashift:SI (subreg:SI (reg:QI 46) 0)
 >>                             (const_int 24 [0x18]))
 >>                  (const_int 24 [0x18]))
 >>
 >> (which is a zero extend) to the equivalent:
 >>
 >>     (subreg:SI (reg:QI 46))
 >>
 >> because the PA-RISC backend defines WORD_REGISTER_OPERATIONS
 >> and LOAD_EXTEND_OP as always ZERO_EXTEND.  This is a symmetric
 >> case to PR c/2454 with zero extension instead of sign extension.
 >
 >Whilst looking through the uses of LOAD_EXTEND_OP, I believe I've
 >found the real problem, and I'm currently bootstrapping and testing
 >the fix on several platforms.
 >
 >The true issue is that LOAD_EXTEND_OP only applies to paradoxical
 >subreg's whose arguments are MEMs, i.e. those that really require
 >a load from memory.
And presumably part of the trick here is that not all require a load
from memory?  For the examples you've looked at, does the paradoxical
subreg eventually get eliminated by other actions in combine?

Yes, it's true that any paradoxical subreg which exists at reload time
will be loaded from memory, but if passes such as combine can eliminate
a paradoxical subreg, then we can't depend on the value being extended
according to LOAD_EXTEND_OP as we can't depend on the value being loaded
from memory.


 >Most uses of LOAD_EXTEND_OP check for the
 >MEM, but a few including those in combine.c's num_sign_bit_copies
 >and nonzero_bits don't.  Adding these missing checks, fixes all
 >five 20011223-1.c failures on v850-elf.
That may indeed be a reasonable fix.


 >The bad news, therefore, is that this isn't the problem with
 >PR target/5169.  Substituting (zero_extend:SI (mem:QI)) for
 >(subreg:SI (mem:QI)) is a valid transformation on PA-RISC where
 >LOAD_EXTEND_OP(QImode) is ZERO_EXTEND.  So the problem with 5169,
 >if it still exists, is elsewhere.  This LOAD_EXTEND_OP bug *is*
 >exhibited on PA, but the example RTL that's in the GNATS entry
 >shows a subreg of a mem, which isn't a problem.
There is a very long discussion of 5169 in the mailing list archives
(Jan 2002 if I recall correctly).

The current sources in combine.c tend to mask the bug pretty well; however,
the code in simplify_comparison has also been bullet-proofed to deal with
this kind of problem.

jeff