Analysis of high priority PR c/2454

[Roger Sayle]

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!

Thanks for catching my mistake.  In the meantime I'd done bootstraps
and regression tests on sh-elf, v850-elf, i686-pc-linux-gnu and also
hppa2.0w-hp-hpux11.00 :>  Preventing this combination fixes the
failure but for all the wrong reasons.


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?

I'll continue my investigation.  Many thanks once agin for your
help, and I apologise for my ever diminishing ignorance of RTL.

Roger
--