Uros Bizjak <ubiz...@gmail.com> writes:
> On Wed, Sep 26, 2012 at 11:22 PM, Eric Botcazou <ebotca...@adacore.com> wrote:
>>> I agree (subreg:M (op:N A C) 0) to (op:M (subreg:N (A 0)) C) is
>>> a good transformation, but why do we need to handle as special
>>> the case where the subreg is itself the operand of a plus or minus?
>>> I think it should happen regardless of where the subreg occurs.
>>
>> Don't we need to restrict this to the low part though?
>
> I have tried this approach with attached patch. Unfortunately,
> although it survived bootstrap without libjava on x86_64, it failed
> building libjava with:
>
> /home/uros/gcc-svn/trunk/libjava/classpath/javax/swing/plaf/basic/BasicSliderUI.java:1299:0:
> error: insn does not satisfy its constraints:
> }
> ^
> (insn 237 398 399 7 (set (reg:SI 1 dx [125])
> (plus:SI (subreg:SI (mult:DI (reg:DI 1 dx [orig:72 D.78627 ] [72])
> (const_int 2 [0x2])) 0)
> (reg:SI 5 di)))
> /home/uros/gcc-svn/trunk/libjava/classpath/javax/swing/plaf/basic/BasicSliderUI.java:1271
> 240 {*leasi}
> (expr_list:REG_DEAD (reg:DI 5 di)
> (nil)))
>
> Original RTX was (subreg:SI (plus:DI (mult:DI (...) reg:DI))), which
> is valid RTX pattern for lea insn, the above is not.
>
> Due to these problems, I think the safer approach is to limit the
> transformation to (plus:SI (subreg:SI (plus:DI (...) 0)) RTXes, as was
> the case with original patch. This approach would fix a specific
> problem where simplify_plus_minus is not able to simplify the combined
> RTX at combine time. Please note, that combined RTXes are always
> checked for correctness at combine pass.
I think instead the (subreg (plus ...)) handling should be applied
to (subreg (mult ...)) too. IMO the correct form of the above address
ought to be:
(set (reg:SI 1 dx [125])
(plus:SI (mult:SI (reg:SI 1 dx [orig:72 D.78627 ] [72])
(const_int 2 [0x2]))
(reg:SI 5 di))
Richard
