[PING ^ 2][RFC PATCH, AARCH64] Add support for -mlong-calls option
Ping again? Any comment please?
Ping? I hope this patch can catch up with stage 1 of GCC-5.0. Thanks.
Hi Felix,
Sorry for the delay responding, I've been out of the office recently
and I'm only just catching up on a backlog of GCC related emails.
I'm in two minds about this; I can potentially see the need for
attributes to enable long calls for specific calls, and maybe also
for pragmas that can be used to efficiently mark a group of
functions in that way; but I don't really see the value in adding a
-mlong-calls option to do
this globally.
The reasoning is as follows: long calls are generally very expensive
and relatively few functions should need them in most applications
(since code that needs to span more than a single block of 128Mbytes
- the span of a BL or B instruction - will be very rare in reality).
The best way to handle very large branches for those rare cases
where you do have a very large contiguous block of code more than
128MB is by having the linker insert veneers when needed; the code
will branch to the veneer which will insert an indirect branch at
that point (the ABI guarantees that at function call boundaries IP0
and IP1 will not contain live values, making them available for such
purposes).
In a very small number of cases it might be desirable to mark
specific functions as being too far away to reach; in those cases
the attributes and pragma methods can be used to mark such calls as being
far calls.
Aside: The reason -mlong-calls was added to GCC for ARM is that the
code there pre-dates the EABI, which introduced the concept of
link-time veneering of calls - the option should be unnecessary now
that almost everyone uses the EABI as the basis for their platform
ABI. We don't have such a legacy for AArch64 and I'd need to see
strong
justification for its use before adding the option there as well.
So please can you rework the patch to remove the -mlong-calls option
and just leave the attribute and pragma interfaces.
R.
Hello Richard,
Thanks for the comments. I agree with the idea.
And I updated the patch with the -mlong-calls option removed and use
short call by default.
Reg-tested for aarch64-linux-gnu with qemu. Is it OK for trunk?
Index: gcc/ChangeLog
=
==
--- gcc/ChangeLog (revision 217394)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,25 @@
+2014-11-12 Felix Yang felix.y...@huawei.com
+ Haijian Zhang z.zhanghaij...@huawei.com
+
+ * config/aarch64/aarch64.h (REGISTER_TARGET_PRAGMAS): Define.
+ * config/aarch64/aarch64.c (aarch64_set_default_type_attributes,
+ aarch64_attribute_table, aarch64_comp_type_attributes,
+ aarch64_decl_is_long_call_p, aarch64_function_in_section_p,
+ aarch64_pr_long_calls, aarch64_pr_no_long_calls,
+ aarch64_pr_long_calls_off): New functions.
+ (TARGET_SET_DEFAULT_TYPE_ATTRIBUTES): Define as
+ aarch64_set_default_type_attributes.
+ (TARGET_ATTRIBUTE_TABLE): Define as aarch64_attribute_table.
+ (TARGET_COMP_TYPE_ATTRIBUTES): Define as
aarch64_comp_type_attribute.
+ (aarch64_pragma_enum): New enum.
+ (aarch64_attribute_table): New attribute table.
+ * config/aarch64/aarch64-protos.h (aarch64_pr_long_calls,
+ aarch64_pr_no_long_calls, aarch64_pr_long_calls_off): New declarations.
+ * config/aarch64/aarch64.md (sibcall, sibcall_value): Modified to
+ generate indirect call for sibling call when needed.
+ * config/aarch64/predicate.md (aarch64_call_insn_operand): Modified to
+ exclude a symbol_ref for an indirect call.
+
2014-11-11 Andrew Pinski apin...@cavium.com
Bug target/61997
Index: gcc/testsuite/gcc.target/aarch64/long-calls-1.c
=
==
--- gcc/testsuite/gcc.target/aarch64/long-calls-1.c (revision 0)
+++ gcc/testsuite/gcc.target/aarch64/long-calls-1.c (revision 0)
@@ -0,0 +1,133 @@
+/* Check that long calls to different sections are not optimized to
+bl. */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+/* This test expects that short calls are the default. */
+/* { dg-skip-if -mlong-calls in use { *-*-* } { -mlong-calls }
+{ } } */
+
+#define section(S) __attribute__((section(S))) #define weak
+__attribute__((weak)) #define noinline __attribute__((noinline))
+#define long_call __attribute__((long_call)) #define short_call
+__attribute__((short_call))
+
+#define REMOTE_CALL(ID, TARGET_ATTRS, CALL_ATTRS) \
+ const char *TARGET_ATTRS ID (void);
\
+ const char *CALL_ATTRS call_##ID (void) { return ID () + 1; }
+
+#define EXTERN_CALL(ID, TARGET_ATTRS, CALL_ATTRS) \
+ const char *TARGET_ATTRS noinline ID (void) { return
Re: [PING ^ 2][RFC PATCH, AARCH64] Add support for -mlong-calls option
On Tue, Nov 18, 2014 at 11:51 AM, Yangfei (Felix) felix.y...@huawei.com wrote:
Ping again? Any comment please?
Pinging daily is only going to irritate people. Please desist from doing so.
Ramana
Ping? I hope this patch can catch up with stage 1 of GCC-5.0. Thanks.
Hi Felix,
Sorry for the delay responding, I've been out of the office recently
and I'm only just catching up on a backlog of GCC related emails.
I'm in two minds about this; I can potentially see the need for
attributes to enable long calls for specific calls, and maybe also
for pragmas that can be used to efficiently mark a group of
functions in that way; but I don't really see the value in adding a
-mlong-calls option to do
this globally.
The reasoning is as follows: long calls are generally very expensive
and relatively few functions should need them in most applications
(since code that needs to span more than a single block of 128Mbytes
- the span of a BL or B instruction - will be very rare in reality).
The best way to handle very large branches for those rare cases
where you do have a very large contiguous block of code more than
128MB is by having the linker insert veneers when needed; the code
will branch to the veneer which will insert an indirect branch at
that point (the ABI guarantees that at function call boundaries IP0
and IP1 will not contain live values, making them available for such
purposes).
In a very small number of cases it might be desirable to mark
specific functions as being too far away to reach; in those cases
the attributes and pragma methods can be used to mark such calls as being
far calls.
Aside: The reason -mlong-calls was added to GCC for ARM is that the
code there pre-dates the EABI, which introduced the concept of
link-time veneering of calls - the option should be unnecessary now
that almost everyone uses the EABI as the basis for their platform
ABI. We don't have such a legacy for AArch64 and I'd need to see
strong
justification for its use before adding the option there as well.
So please can you rework the patch to remove the -mlong-calls option
and just leave the attribute and pragma interfaces.
R.
Hello Richard,
Thanks for the comments. I agree with the idea.
And I updated the patch with the -mlong-calls option removed and use
short call by default.
Reg-tested for aarch64-linux-gnu with qemu. Is it OK for trunk?
Index: gcc/ChangeLog
=
==
--- gcc/ChangeLog (revision 217394)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,25 @@
+2014-11-12 Felix Yang felix.y...@huawei.com
+ Haijian Zhang z.zhanghaij...@huawei.com
+
+ * config/aarch64/aarch64.h (REGISTER_TARGET_PRAGMAS): Define.
+ * config/aarch64/aarch64.c (aarch64_set_default_type_attributes,
+ aarch64_attribute_table, aarch64_comp_type_attributes,
+ aarch64_decl_is_long_call_p, aarch64_function_in_section_p,
+ aarch64_pr_long_calls, aarch64_pr_no_long_calls,
+ aarch64_pr_long_calls_off): New functions.
+ (TARGET_SET_DEFAULT_TYPE_ATTRIBUTES): Define as
+ aarch64_set_default_type_attributes.
+ (TARGET_ATTRIBUTE_TABLE): Define as aarch64_attribute_table.
+ (TARGET_COMP_TYPE_ATTRIBUTES): Define as
aarch64_comp_type_attribute.
+ (aarch64_pragma_enum): New enum.
+ (aarch64_attribute_table): New attribute table.
+ * config/aarch64/aarch64-protos.h (aarch64_pr_long_calls,
+ aarch64_pr_no_long_calls, aarch64_pr_long_calls_off): New declarations.
+ * config/aarch64/aarch64.md (sibcall, sibcall_value): Modified to
+ generate indirect call for sibling call when needed.
+ * config/aarch64/predicate.md (aarch64_call_insn_operand): Modified to
+ exclude a symbol_ref for an indirect call.
+
2014-11-11 Andrew Pinski apin...@cavium.com
Bug target/61997
Index: gcc/testsuite/gcc.target/aarch64/long-calls-1.c
=
==
--- gcc/testsuite/gcc.target/aarch64/long-calls-1.c (revision 0)
+++ gcc/testsuite/gcc.target/aarch64/long-calls-1.c (revision 0)
@@ -0,0 +1,133 @@
+/* Check that long calls to different sections are not optimized to
+bl. */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+/* This test expects that short calls are the default. */
+/* { dg-skip-if -mlong-calls in use { *-*-* } { -mlong-calls }
+{ } } */
+
+#define section(S) __attribute__((section(S))) #define weak
+__attribute__((weak)) #define noinline __attribute__((noinline))
+#define long_call __attribute__((long_call)) #define short_call
+__attribute__((short_call))
+
+#define REMOTE_CALL(ID, TARGET_ATTRS, CALL_ATTRS) \
+ const char *TARGET_ATTRS ID (void);
\
+ const char *CALL_ATTRS call_##ID
Re: [PING ^ 2][RFC PATCH, AARCH64] Add support for -mlong-calls option
On Tue, Nov 18, 2014 at 11:51 AM, Yangfei (Felix) felix.y...@huawei.com
wrote:
Ping again? Any comment please?
Pinging daily is only going to irritate people. Please desist from doing so.
Ramana
Oh, thanks for reminding me. And sorry if this bothers you guys.
The end of stage1 of GCC 5.0 causes me to push this a little bit :-)
Ping? I hope this patch can catch up with stage 1 of GCC-5.0. Thanks.
Hi Felix,
Sorry for the delay responding, I've been out of the office
recently and I'm only just catching up on a backlog of GCC related
emails.
I'm in two minds about this; I can potentially see the need for
attributes to enable long calls for specific calls, and maybe
also for pragmas that can be used to efficiently mark a group of
functions in that way; but I don't really see the value in adding
a -mlong-calls option to do
this globally.
The reasoning is as follows: long calls are generally very
expensive and relatively few functions should need them in most
applications (since code that needs to span more than a single
block of 128Mbytes
- the span of a BL or B instruction - will be very rare in reality).
The best way to handle very large branches for those rare cases
where you do have a very large contiguous block of code more than
128MB is by having the linker insert veneers when needed; the
code will branch to the veneer which will insert an indirect
branch at that point (the ABI guarantees that at function call
boundaries IP0 and IP1 will not contain live values, making them
available
for such purposes).
In a very small number of cases it might be desirable to mark
specific functions as being too far away to reach; in those cases
the attributes and pragma methods can be used to mark such calls
as being
far calls.
Aside: The reason -mlong-calls was added to GCC for ARM is that
the code there pre-dates the EABI, which introduced the concept
of link-time veneering of calls - the option should be
unnecessary now that almost everyone uses the EABI as the basis
for their platform ABI. We don't have such a legacy for AArch64
and I'd need to see strong
justification for its use before adding the option there as well.
So please can you rework the patch to remove the -mlong-calls
option and just leave the attribute and pragma interfaces.
R.
Hello Richard,
Thanks for the comments. I agree with the idea.
And I updated the patch with the -mlong-calls option removed and
use short call by default.
Reg-tested for aarch64-linux-gnu with qemu. Is it OK for trunk?
Index: gcc/ChangeLog
=
==
--- gcc/ChangeLog (revision 217394)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,25 @@
+2014-11-12 Felix Yang felix.y...@huawei.com
+ Haijian Zhang z.zhanghaij...@huawei.com
+
+ * config/aarch64/aarch64.h (REGISTER_TARGET_PRAGMAS): Define.
+ * config/aarch64/aarch64.c (aarch64_set_default_type_attributes,
+ aarch64_attribute_table, aarch64_comp_type_attributes,
+ aarch64_decl_is_long_call_p, aarch64_function_in_section_p,
+ aarch64_pr_long_calls, aarch64_pr_no_long_calls,
+ aarch64_pr_long_calls_off): New functions.
+ (TARGET_SET_DEFAULT_TYPE_ATTRIBUTES): Define as
+ aarch64_set_default_type_attributes.
+ (TARGET_ATTRIBUTE_TABLE): Define as aarch64_attribute_table.
+ (TARGET_COMP_TYPE_ATTRIBUTES): Define as
aarch64_comp_type_attribute.
+ (aarch64_pragma_enum): New enum.
+ (aarch64_attribute_table): New attribute table.
+ * config/aarch64/aarch64-protos.h (aarch64_pr_long_calls,
+ aarch64_pr_no_long_calls, aarch64_pr_long_calls_off): New
declarations.
+ * config/aarch64/aarch64.md (sibcall, sibcall_value): Modified to
+ generate indirect call for sibling call when needed.
+ * config/aarch64/predicate.md (aarch64_call_insn_operand): Modified
to
+ exclude a symbol_ref for an indirect call.
+
2014-11-11 Andrew Pinski apin...@cavium.com
Bug target/61997
Index: gcc/testsuite/gcc.target/aarch64/long-calls-1.c
=
==
--- gcc/testsuite/gcc.target/aarch64/long-calls-1.c (revision 0)
+++ gcc/testsuite/gcc.target/aarch64/long-calls-1.c (revision 0)
@@ -0,0 +1,133 @@
+/* Check that long calls to different sections are not optimized
+to bl. */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+/* This test expects that short calls are the default. */
+/* { dg-skip-if -mlong-calls in use { *-*-* } { -mlong-calls
+} { } } */
+
+#define section(S) __attribute__((section(S))) #define weak
+__attribute__((weak)) #define noinline __attribute__((noinline))
+#define
Re: [PING ^ 2][RFC PATCH, AARCH64] Add support for -mlong-calls option
On 18/11/14 12:51, Yangfei (Felix) wrote:
On Tue, Nov 18, 2014 at 11:51 AM, Yangfei (Felix) felix.y...@huawei.com
wrote:
Ping again? Any comment please?
Pinging daily is only going to irritate people. Please desist from doing so.
Ramana
Oh, thanks for reminding me. And sorry if this bothers you guys.
The end of stage1 of GCC 5.0 causes me to push this a little bit :-)
You've posted this patch before stage1 closed. In any case IIRC the
policy in the contribute pages used to suggest a weekly ping.
Ramana
Ping? I hope this patch can catch up with stage 1 of GCC-5.0. Thanks.
Hi Felix,
Sorry for the delay responding, I've been out of the office
recently and I'm only just catching up on a backlog of GCC related emails.
I'm in two minds about this; I can potentially see the need for
attributes to enable long calls for specific calls, and maybe
also for pragmas that can be used to efficiently mark a group of
functions in that way; but I don't really see the value in adding
a -mlong-calls option to do
this globally.
The reasoning is as follows: long calls are generally very
expensive and relatively few functions should need them in most
applications (since code that needs to span more than a single
block of 128Mbytes
- the span of a BL or B instruction - will be very rare in reality).
The best way to handle very large branches for those rare cases
where you do have a very large contiguous block of code more than
128MB is by having the linker insert veneers when needed; the
code will branch to the veneer which will insert an indirect
branch at that point (the ABI guarantees that at function call
boundaries IP0 and IP1 will not contain live values, making them available
for such purposes).
In a very small number of cases it might be desirable to mark
specific functions as being too far away to reach; in those cases
the attributes and pragma methods can be used to mark such calls
as being
far calls.
Aside: The reason -mlong-calls was added to GCC for ARM is that
the code there pre-dates the EABI, which introduced the concept
of link-time veneering of calls - the option should be
unnecessary now that almost everyone uses the EABI as the basis
for their platform ABI. We don't have such a legacy for AArch64
and I'd need to see strong
justification for its use before adding the option there as well.
So please can you rework the patch to remove the -mlong-calls
option and just leave the attribute and pragma interfaces.
R.
Hello Richard,
Thanks for the comments. I agree with the idea.
And I updated the patch with the -mlong-calls option removed and
use short call by default.
Reg-tested for aarch64-linux-gnu with qemu. Is it OK for trunk?
Index: gcc/ChangeLog
=
==
--- gcc/ChangeLog (revision 217394)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,25 @@
+2014-11-12 Felix Yang felix.y...@huawei.com
+ Haijian Zhang z.zhanghaij...@huawei.com
+
+ * config/aarch64/aarch64.h (REGISTER_TARGET_PRAGMAS): Define.
+ * config/aarch64/aarch64.c (aarch64_set_default_type_attributes,
+ aarch64_attribute_table, aarch64_comp_type_attributes,
+ aarch64_decl_is_long_call_p, aarch64_function_in_section_p,
+ aarch64_pr_long_calls, aarch64_pr_no_long_calls,
+ aarch64_pr_long_calls_off): New functions.
+ (TARGET_SET_DEFAULT_TYPE_ATTRIBUTES): Define as
+ aarch64_set_default_type_attributes.
+ (TARGET_ATTRIBUTE_TABLE): Define as aarch64_attribute_table.
+ (TARGET_COMP_TYPE_ATTRIBUTES): Define as
aarch64_comp_type_attribute.
+ (aarch64_pragma_enum): New enum.
+ (aarch64_attribute_table): New attribute table.
+ * config/aarch64/aarch64-protos.h (aarch64_pr_long_calls,
+ aarch64_pr_no_long_calls, aarch64_pr_long_calls_off): New
declarations.
+ * config/aarch64/aarch64.md (sibcall, sibcall_value): Modified to
+ generate indirect call for sibling call when needed.
+ * config/aarch64/predicate.md (aarch64_call_insn_operand): Modified
to
+ exclude a symbol_ref for an indirect call.
+
2014-11-11 Andrew Pinski apin...@cavium.com
Bug target/61997
Index: gcc/testsuite/gcc.target/aarch64/long-calls-1.c
=
==
--- gcc/testsuite/gcc.target/aarch64/long-calls-1.c (revision 0)
+++ gcc/testsuite/gcc.target/aarch64/long-calls-1.c (revision 0)
@@ -0,0 +1,133 @@
+/* Check that long calls to different sections are not optimized
+to bl. */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+/* This test expects that short calls are the default. */
+/* { dg-skip-if -mlong-calls in use { *-*-* } { -mlong-calls
+} { } } */
+
+#define section(S) __attribute__((section(S))) #define weak
+__attribute__((weak)) #define noinline __attribute__((noinline))
+#define long_call __attribute__((long_call)) #define short_call
+__attribute__((short_call))
+
+#define REMOTE_CALL(ID, TARGET_ATTRS, CALL_ATTRS)
\
+ const char
