Yvan,

On Wed, Dec 11, 2013 at 10:35 AM, Yvan Roux <yvan.r...@linaro.org> wrote:
> Hi Vladimir,
>
> I've some regressions on ARM after this SP elimination patch, and they
> are execution failures.  Here is the list:

Pragmatically, I think it's time we turned LRA on by default now that
we are in stage3 and that would help with getting more issues out of
the auto-testers quicker than anything else. Given we are now well
into stage3, we should make sure that the LRA support gets as much
testing as it can get in the run-up to the release.

Can you prepare a patch for this please ?

regards
Ramana



>
> g++.dg/cilk-plus/AN/array_test_ND_tplt.cc  -O3 -fcilkplus
> gcc.c-torture/execute/va-arg-22.c  -O2
> gcc.dg/atomic/c11-atomic-exec-5.c  -O0
> gfortran.dg/direct_io_12.f90  -O[23]
> gfortran.dg/elemental_dependency_1.f90  -O2
> gfortran.dg/matmul_2.f90  -O2
> gfortran.dg/matmul_6.f90  -O2
> gfortran.dg/mvbits_7.f90  -O3
> gfortran.dg/unlimited_polymorphic_1.f03  -O3
>
> I reduced and looked at var-arg-22.c and the issue is that in
> lra_eliminate_regs_1  (called by get_equiv_with_elimination) we
> transformed sfp + 0x4c in sp + 0xfc because of a bad sp offset.  What
> we try to do here is to change the pseudo 195 of the insn 118 below :
>
> (insn 118 114 112 8 (set (reg:DI 195)
>         (unspec:DI [
>                 (mem:DI (plus:SI (reg/f:SI 215)
>                         (const_int 8 [0x8])) [7 MEM[(struct A35 *)_12
> + 64B]+8 S8 A8])
>             ] UNSPEC_UNALIGNED_LOAD)) v2.c:49 146 {unaligned_loaddi}
>      (expr_list:REG_EQUIV (mem/c:DI (plus:SI (reg/f:SI 192)
>                 (const_int 8 [0x8])) [7 a35+8 S8 A32])
>         (nil)))
>
> with its equivalent (x arg of lra_eliminate_regs_1):
>
> (mem/c:DI (plus:SI (reg/f:SI 102 sfp)
>         (const_int 76 [0x4c])) [7 a35+8 S8 A32])
>
> lra_eliminate_regs_1 is called with full_p = true (it is not really
> clear for what it means), but in the PLUS switch case, we have offset
> = 0xb (given by ep->offset) and  as lra_get_insn_recog_data
> (insn)->sp_offset value is 0, we will indeed add 0xb to the original
> 0x4c offset.
>
> So, here I don't get if it is the sp_offset value of the
> lra_insn_recog_data element which is not well updated or if lra_
> eliminate_regs_1 has to be called with update_p and not full_p (which
> fixed the value in that particular case).  Is it more obvious for you
> ?
>
> Thanks
> Yvan
>
>
> On 3 December 2013 16:39, Vladimir Makarov <vmaka...@redhat.com> wrote:
>> On 12/3/2013, 6:54 AM, Marcus Shawcroft wrote:
>>>
>>> On 2 December 2013 23:44, Vladimir Makarov <vmaka...@redhat.com> wrote:
>>>
>>>> If somebody with the rights approves, I can commit it tomorrow.
>>>>
>>>> 2013-12-02  Vladimir Makarov  <vmaka...@redhat.com>
>>>>
>>>>          * config/aarch64/aarch64.c (aarch64_frame_pointer_required):
>>>> Check
>>>>          LR_REGNUM.
>>>>          (aarch64_can_eliminate): Don't check elimination source when
>>>>          frame_pointer_requred is false.
>>>>
>>>
>>>
>>> This is fine with me, go ahead and commit it.  Thanks /Marcus
>>>
>> Committed as rev. 205637 with changelog fix of a typo found by Jeff.
>>

Reply via email to