On Fri, Oct 12, 2012 at 11:13 PM, Ramana Radhakrishnan
<ramana....@googlemail.com> wrote:
> On Tue, Sep 25, 2012 at 5:32 PM, Dinar Temirbulatov
> <dtemirbula...@gmail.com> wrote:
>> Hi Ramana,
>> Here is obvious fix for PR49423, I just added pool range for
>
> Sorry for the late response - I've been on vacation.
>
> No it's not ok. These were removed deliberately and subsequent
> efforts to put these back on have been rejected as being incomplete.
> Please investigate why reload wants to reload the load of a constant 0
> which is a valid constant for HImode values into the constant pool .
> In addition it might be that movhi_insn needs to grow support for movw
> at the right architecture level.
>
> With your patch and for example 920928-2.c you'll start seeing 0 going
> into the constant pool and an ldrh out of that !
In my case (scal-to-vec2.c at -O1 -msoft-float), the register pressure
is huge and ira (not reload as far as I can tell) was trying to reduce
it slightly by generating the constant (0x3002) which was pulled out
of the loop.
The register allocator (IRA or reload) got so confused it changed:
(insn 357 355 358 7 (set (reg:SI 372 [ D.4448 ])
(zero_extend:SI (subreg:HI (reg:SI 745 [ D.4141+4 ]) 0)))
src/gcc/testsuite/gcc.c-torture/execute/scal-to-vec2.c:49 161
{*arm_zero_extendhisi2_v6}
(nil))
Into:
(insn 357 1072 1075 7 (set (reg:SI 8 r8)
(zero_extend:SI (mem/u/c:HI (symbol_ref/u:SI ("*.LC0") [flags
0x2]) [0 S2 A16])))
src/gcc/testsuite/gcc.c-torture/execute/scal-to-vec2.c:49 161
{*arm_zero_extendhisi2_v6}
(nil))
(insn 1075 357 1077 7 (set (mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -60 [0xffffffffffffffc4])) [0 %sfp+-24 S4 A32])
(reg:SI 8 r8))
src/gcc/testsuite/gcc.c-torture/execute/scal-to-vec2.c:49 181
{*arm_movsi_insn}
(nil))
Thanks,
Andrew Pinski
>
> regards
> Ramana
