diff mbox

[AArch64] LR register not used in leaf functions

Message ID 54204387.5090105@linaro.org
State New
Headers show

Commit Message

Kugan Vivekanandarajah Sept. 22, 2014, 3:43 p.m. UTC
AArch64 has the same issue ARM had where the LR register was not used in
leaf functions. This was reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017. In AArch64, this
test-case need to be added with more live ranges for the need for the
LR_REGNUM. i.e test-case in the PR needs additional loops up to r31 for
the case AArch64 to see this.

The same fix (from the thread
https://gcc.gnu.org/ml/gcc-patches/2011-04/msg02191.html) which went
into ARM should apply to AArch64 as well. Regression tested on qemu for
aarch64-none-linux-gnu with no new regressions. Is this OK for trunk?

Thanks,
Kugan


gcc/ChangeLog:

2014-09-23  Kugan Vivekanandarajah  <kuganv@linaro.org>

	* config/aarch64/aarch64.h (EPILOGUE_USES): Return true only after
	epilogue_completed is true.

Comments

Jiong Wang Sept. 22, 2014, 3:58 p.m. UTC | #1
On 22/09/14 16:43, Kugan wrote:

> AArch64 has the same issue ARM had where the LR register was not used in
> leaf functions. This was reported in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017. In AArch64, this
> test-case need to be added with more live ranges for the need for the
> LR_REGNUM. i.e test-case in the PR needs additional loops up to r31 for
> the case AArch64 to see this.
>
> The same fix (from the thread
> https://gcc.gnu.org/ml/gcc-patches/2011-04/msg02191.html) which went
> into ARM should apply to AArch64 as well. Regression tested on qemu for
> aarch64-none-linux-gnu with no new regressions. Is this OK for trunk?
This still be a partial fix. LR should be a caller-saved register free
to use in case it's saved properly to across function call.

I had a very similar patch to this sitting in my local tree and under
various benchmark analysis.

-- Jiong
>
> Thanks,
> Kugan
>
>
> gcc/ChangeLog:
>
> 2014-09-23  Kugan Vivekanandarajah  <kuganv@linaro.org>
>
> 	* config/aarch64/aarch64.h (EPILOGUE_USES): Return true only after
> 	epilogue_completed is true.
>
Kugan Vivekanandarajah Sept. 27, 2014, 9:20 p.m. UTC | #2
On 23/09/14 01:58, Jiong Wang wrote:
> On 22/09/14 16:43, Kugan wrote:
> 
>> AArch64 has the same issue ARM had where the LR register was not used in
>> leaf functions. This was reported in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017. In AArch64, this
>> test-case need to be added with more live ranges for the need for the
>> LR_REGNUM. i.e test-case in the PR needs additional loops up to r31 for
>> the case AArch64 to see this.
>>
>> The same fix (from the thread
>> https://gcc.gnu.org/ml/gcc-patches/2011-04/msg02191.html) which went
>> into ARM should apply to AArch64 as well. Regression tested on qemu for
>> aarch64-none-linux-gnu with no new regressions. Is this OK for trunk?
> This still be a partial fix. LR should be a caller-saved register free
> to use in case it's saved properly to across function call.

Indeed. This should be improved from the generic code. Right now, if a
hard register is used in EPILOGUE_USES, it conflicts with all the live
ranges till a call site kills.  I think we should have this patch till
the generic code can be improved.

Thanks,
Kugan

> 
> I had a very similar patch to this sitting in my local tree and under
> various benchmark analysis.
> 
> -- Jiong
>>
>> Thanks,
>> Kugan
>>
>>
>> gcc/ChangeLog:
>>
>> 2014-09-23  Kugan Vivekanandarajah  <kuganv@linaro.org>
>>
>>     * config/aarch64/aarch64.h (EPILOGUE_USES): Return true only after
>>     epilogue_completed is true.
>>
> 
>
diff mbox

Patch

diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index db950da..b3e4585 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -309,7 +309,7 @@  extern unsigned long aarch64_tune_flags;
    considered live at the start of the called function.  */
 
 #define EPILOGUE_USES(REGNO) \
-  ((REGNO) == LR_REGNUM)
+  (epilogue_completed && (REGNO) == LR_REGNUM)
 
 /* EXIT_IGNORE_STACK should be nonzero if, when returning from a function,
    the stack pointer does not matter.  The value is tested only in