cse creates non-canonical PLUS

[apl at alum dot mit dot edu]

It looks like the first cse pass is constructing non-canonical
plusses.

What we basically have is RTL that looks like...

(insn 9 50 11 (set (reg/f:QI 25)
        (symbol_ref:QI ("bs"))) -1 (nil)
    (expr_list:REG_EQUAL (symbol_ref:QI ("bs"))
        (nil)))
...
(insn 17 15 19 (set (reg/f:QI 28)
        (plus:QI (reg/f:QI 25)
            (const_int 1 [0x1]))) -1 (nil)
    (nil))


The CSE pass comes along and decides that it would be cost-effective
if INSN 17 used the constant value in pseudo 25 instead of the
register.

(insn 17 15 19 (set (reg/f:QI 28)
        (plus:QI (symbol_ref:QI ("bs"))
            (const_int 1 [0x1]))) 15 {*tpc.md:748} (nil)
    (expr_list:REG_EQUAL (const:QI (plus:QI (symbol_ref:QI ("bs"))
                (const_int 1 [0x1])))
        (nil)))


cse_insn() is calling fold_rtx() on

        (plus:QI (reg/f:QI 25)
            (const_int 1 [0x1]))) -1 (nil)

and that substitutes in the SYMBOL_REF without canonicalizing.

fold_rtx returns a properly CONST-wrapped PLUS, but the damage is
already done to the insn....

Not sure how to fix this correctly.  I would guess that making
fold_rtx smarter about PLUS might be part of the solution, but
would eagerly defer to someone more knowledgeable on CSE.....

I suppose the OTHER approach would be to insure that as fold_rtx
unwinds from its recursive tree walk that it should always make
certain that the folded tree replaces the operand it just
processed....

The test case that's failing for me is
gcc.c-torture/compile/20000802-1.c with -O1, but this is on a new
port, so I doubt this is trivial to reproduce in a standard release.