Message ID | 529D1B4E.5070304@redhat.com |
---|---|
State | New |
Headers | show |
On 12/02/13 16:44, Vladimir Makarov wrote: > > > First of all, it is a bad situation for code performance when IRA > decides that it can use frame pointer for allocation, and after that > LRA/reload decides that frame pointer can not be used and spills all > pseudos assigned to FP. The generated code will be much worse than > one generated if we decided not to use FP from the IRA start. Yup. Actually, I think we had the same problem with the old local/global/reload allocator as well. I don't recall the specifics, but I think the problem was global thought it could eliminate FP, but reload didn't and as a result code generation suffered. I don't recall ever auditing ports to see if they were vulnerable to this class of problem. So there may be others that will might trigger the assert. > > 2013-12-02 Vladimir Makarov <vmakarov@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. s/frame_pointer_requred/frame_pointer_required in the ChangeLog entry. jeff
On 2 December 2013 23:44, Vladimir Makarov <vmakarov@redhat.com> wrote: > If somebody with the rights approves, I can commit it tomorrow. > > 2013-12-02 Vladimir Makarov <vmakarov@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
On 12/3/2013, 6:54 AM, Marcus Shawcroft wrote: > On 2 December 2013 23:44, Vladimir Makarov <vmakarov@redhat.com> wrote: > >> If somebody with the rights approves, I can commit it tomorrow. >> >> 2013-12-02 Vladimir Makarov <vmakarov@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.
Hi Vladimir, I've some regressions on ARM after this SP elimination patch, and they are execution failures. Here is the list: 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 <vmakarov@redhat.com> wrote: > On 12/3/2013, 6:54 AM, Marcus Shawcroft wrote: >> >> On 2 December 2013 23:44, Vladimir Makarov <vmakarov@redhat.com> wrote: >> >>> If somebody with the rights approves, I can commit it tomorrow. >>> >>> 2013-12-02 Vladimir Makarov <vmakarov@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. >
Yvan, On Wed, Dec 11, 2013 at 10:35 AM, Yvan Roux <yvan.roux@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 <vmakarov@redhat.com> wrote: >> On 12/3/2013, 6:54 AM, Marcus Shawcroft wrote: >>> >>> On 2 December 2013 23:44, Vladimir Makarov <vmakarov@redhat.com> wrote: >>> >>>> If somebody with the rights approves, I can commit it tomorrow. >>>> >>>> 2013-12-02 Vladimir Makarov <vmakarov@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. >>
> 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. I agree. > Can you prepare a patch for this please ? I'll post the patch on the list. Thanks, Yvan
On 12/11/2013, 5:35 AM, Yvan Roux wrote: > Hi Vladimir, > > I've some regressions on ARM after this SP elimination patch, and they > are execution failures. Here is the list: > > 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), It means we use full offset between the regs, otherwise we use change in the full offset from the previous iteration (it can be changed as we reserve stack memory for spilled pseudos and the reservation can be done several times). As equiv value is stored as it was before any elimination, we need always to use full offset to make elimination. 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. > 0 value is suspicious because it is default. We might have not set up it from neighbor insns. > 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 > ? > Yvan, could you send me the reduced preprocessed case and the options for cc1 to reproduce it.
On 11 December 2013 19:25, Vladimir Makarov <vmakarov@redhat.com> wrote: > On 12/11/2013, 5:35 AM, Yvan Roux wrote: >> >> Hi Vladimir, >> >> I've some regressions on ARM after this SP elimination patch, and they >> are execution failures. Here is the list: >> >> 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), > > > It means we use full offset between the regs, otherwise we use change in the > full offset from the previous iteration (it can be changed as we reserve > stack memory for spilled pseudos and the reservation can be done several > times). As equiv value is stored as it was before any elimination, we need > always to use full offset to make elimination. Ok thanks it's clearer. > 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. >> > > 0 value is suspicious because it is default. We might have not set up it > from neighbor insns. > > > >> 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 >> ? >> > > Yvan, could you send me the reduced preprocessed case and the options for > cc1 to reproduce it. Here is cc1 command line : cc1 -quiet -march=armv7-a -mtune=cortex-a15 -mfloat-abi=hard -mfpu=neon -mthumb v2.c -O2 I use a native build on a chromebook, but it's reproducible with a cross compiler. With the attached test case the issue is when processing insn 118. Thanks, Yvan
On 12/11/2013, 1:59 PM, Yvan Roux wrote: > On 11 December 2013 19:25, Vladimir Makarov <vmakarov@redhat.com> wrote: >> On 12/11/2013, 5:35 AM, Yvan Roux wrote: >>> >>> Hi Vladimir, >>> >>> I've some regressions on ARM after this SP elimination patch, and they >>> are execution failures. Here is the list: >>> >>> 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), >> >> >> It means we use full offset between the regs, otherwise we use change in the >> full offset from the previous iteration (it can be changed as we reserve >> stack memory for spilled pseudos and the reservation can be done several >> times). As equiv value is stored as it was before any elimination, we need >> always to use full offset to make elimination. > > Ok thanks it's clearer. > >> 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. >>> >> >> 0 value is suspicious because it is default. We might have not set up it >> from neighbor insns. >> >> >> >>> 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 >>> ? >>> >> >> Yvan, could you send me the reduced preprocessed case and the options for >> cc1 to reproduce it. > > > Here is cc1 command line : > > cc1 -quiet -march=armv7-a -mtune=cortex-a15 -mfloat-abi=hard > -mfpu=neon -mthumb v2.c -O2 > > I use a native build on a chromebook, but it's reproducible with a > cross compiler. > > With the attached test case the issue is when processing insn 118. The offset is updated two times and that is wrong. That is because memory in init insn is shared by ira_reg_equiv and the test involves 2 equivalent substitutions. As I wrote equiv should be stored in original form by the current patch design. Simple copying will not work as the first substitution is not done in this case. I need some time to think how to fix it better still I'll try to fix it tomorrow. I expected that the patch might have some problems. The patch code is quite big although it is just a long standing PR fix. Therefore that was my first PR fixed on stage 3. It is good to have it tested earlier and sorry to break some arm tests.
Thanks for your help Vlad. Another bad news about this PR fix, is that it has resurrected the thumb_movhi_clobber bug (PR 58785) but in a different manner as the original failing testcase still pass. I attached a testcase to be compiled with : cc1 -mthumb -mcpu=cortex-m0 -O2 m.c And Thumb bootstrap seems to be broken with an ICE in check_rtl, I'm checking if it is the same issue. Yvan On 12 December 2013 20:18, Vladimir Makarov <vmakarov@redhat.com> wrote: > On 12/11/2013, 1:59 PM, Yvan Roux wrote: >> >> On 11 December 2013 19:25, Vladimir Makarov <vmakarov@redhat.com> wrote: >>> >>> On 12/11/2013, 5:35 AM, Yvan Roux wrote: >>>> >>>> >>>> Hi Vladimir, >>>> >>>> I've some regressions on ARM after this SP elimination patch, and they >>>> are execution failures. Here is the list: >>>> >>>> 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), >>> >>> >>> >>> It means we use full offset between the regs, otherwise we use change in >>> the >>> full offset from the previous iteration (it can be changed as we reserve >>> stack memory for spilled pseudos and the reservation can be done several >>> times). As equiv value is stored as it was before any elimination, we >>> need >>> always to use full offset to make elimination. >> >> >> Ok thanks it's clearer. >> >>> 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. >>>> >>> >>> 0 value is suspicious because it is default. We might have not set up it >>> from neighbor insns. >>> >>> >>> >>>> 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 >>>> ? >>>> >>> >>> Yvan, could you send me the reduced preprocessed case and the options for >>> cc1 to reproduce it. >> >> >> >> Here is cc1 command line : >> >> cc1 -quiet -march=armv7-a -mtune=cortex-a15 -mfloat-abi=hard >> -mfpu=neon -mthumb v2.c -O2 >> >> I use a native build on a chromebook, but it's reproducible with a >> cross compiler. >> >> With the attached test case the issue is when processing insn 118. > > > The offset is updated two times and that is wrong. That is because memory > in init insn is shared by ira_reg_equiv and the test involves 2 equivalent > substitutions. As I wrote equiv should be stored in original form by the > current patch design. Simple copying will not work as the first > substitution is not done in this case. > > I need some time to think how to fix it better still I'll try to fix it > tomorrow. I expected that the patch might have some problems. The patch > code is quite big although it is just a long standing PR fix. Therefore that > was my first PR fixed on stage 3. It is good to have it tested earlier and > sorry to break some arm tests. > >
Index: ../../gcc/gcc/config/aarch64/aarch64.c =================================================================== --- ../../gcc/gcc/config/aarch64/aarch64.c (revision 205590) +++ ../../gcc/gcc/config/aarch64/aarch64.c (working copy) @@ -1703,7 +1703,7 @@ aarch64_frame_pointer_required (void) if (flag_omit_frame_pointer && !faked_omit_frame_pointer) return false; else if (flag_omit_leaf_frame_pointer) - return !crtl->is_leaf; + return !crtl->is_leaf || df_regs_ever_live_p (LR_REGNUM); return true; } @@ -4126,7 +4126,7 @@ aarch64_can_eliminate (const int from, c of faked_omit_frame_pointer here (which is true when we always wish to keep non-leaf frame pointers but only wish to keep leaf frame pointers when LR is clobbered). */ - if (from == FRAME_POINTER_REGNUM && to == STACK_POINTER_REGNUM + if (to == STACK_POINTER_REGNUM && df_regs_ever_live_p (LR_REGNUM) && faked_omit_frame_pointer) return false;