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.0207012329060.29956-100000@www.eyesopen.com>, Roger S
ayle writes:
 >
 >Hi Richard and Jeff,
 >> But doesn't reload *force* a reload of paradoxical SUBREGs, so that they
 >> *always* come from memory?  It *used* to, but perhaps that has changed.
 >> If it still does, something is odd here.
 >
 >Many thanks to both of you for pointing out that I was barking up the
 >wrong tree, and that reload takes care of all paradoxical subregs.
 >
 >The sequence of events is that the following instructions
 >
 >(insn 31 30 32 (set (reg:SI 47)
 >        (ashift:SI (subreg:SI (reg:QI 46) 0)
 >            (const_int 24 [0x18]))) 51 {ashlsi3} (insn_list 30 (nil))
 >    (expr_list:REG_DEAD (reg:QI 46)
 >        (nil)))
 >
 >(insn 32 31 34 (set (reg:SI 45)
 >        (ashiftrt:SI (reg:SI 47)
 >            (const_int 24 [0x18]))) 53 {ashrsi3} (insn_list 31 (nil))
 >    (expr_list:REG_DEAD (reg:SI 47)
 >        (expr_list:REG_EQUAL (sign_extend:SI (reg:QI 46))
 >            (nil))))
 >
 >(insn 34 32 35 (set (reg:SI 48)
 >        (const_int 255 [0xff])) 4 {*movsi_internal} (nil)
 >    (expr_list:REG_EQUAL (const_int 255 [0xff])
 >        (nil)))
 >
 >(insn 35 34 36 (set (cc0)
 >        (compare (reg:SI 45)
 >            (reg:SI 48))) 10 {cmpsi} (insn_list 32 (insn_list 34 (nil)))
 >    (expr_list:REG_DEAD (reg:SI 45)
 >        (expr_list:REG_DEAD (reg:SI 48)
 >            (nil))))
 >
 >are combined into the single instruction:
 >
 >(insn 35 34 36 (set (cc0)
 >        (compare (subreg:SI (reg:QI 46) 0)
 >            (const_int -1 [0xffffffff]))) 10 {cmpsi} (insn_list 30 (nil))
 >    (expr_list:REG_DEAD (reg:QI 46)
 >        (nil)))
 >
 >I'd thought that the problem was the "(subreg:SI (reg:QI 46) 0)" that
 >has thrown away the explicit sign extension. but survives combine.
 >Prompted by your e-mails, I tracked the fate of this paradoxical subreg,
 >it survives until reload where its appropriately loaded from memory.
 >Double checking the NEC V850 architecture manuals, ld.b is indeed a
 >sign extension.  Doh!
 >
[ ... ]
 >
 >But back to the RTL "combination" above.  The true problem (take 3)
 >is with the other operand of the instruction.  "(reg:SI 48)" which
 >should have the value 255, has been replaced with the value -1.
 >How did that happen?
This is why I (*%@#$ hate paradoxical subregs.  Their semantics aren't
clear and they must one day die.

If you go back to the old thread for 5169 you'll find the discussion
regarding the semantics of paradoxical subregs.   The underlying problem
is some parts of the compiler treat them as "don't care bits, assume
whatever value is convenient" when in fact we really do care about them
(particularly for comparisons).

Some parts of the compiler (particularly combine) try to optimize code
based on the "don't care, assume whatever value is convenient" semantics.
If you assume those semantics, then the following two expressions are
equivalent:

(compare (subreg:SI (reg:QI 46) (const_int -1))

(compare (subreg:SI (reg:QI 46) (const_int 255))

But as we know, the comparison is going to look at those upper 24 bits of
(reg:QI 46)), that's the reality of comparison instructions.  Thus those
upper 24 bits of the register (and the constant) are very significant.

With the problems we've had with these lame semantics I'm very very
tempted to ask you to rip that code out of the compiler.  It's been
nothing but trouble.  


jeff