* [PATCH] LoongArch: add addr_global attribute
@ 2022-07-29 14:22 Xi Ruoyao
2022-07-29 15:31 ` [PATCH v2] " Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-07-29 14:22 UTC (permalink / raw)
To: gcc-patches, Lulu Cheng
Cc: xuchenghua, Wang Xuerui, Huacai Chen, Jinyang He, Youling Tang
Background:
https://lore.kernel.org/loongarch/d7670b60-2782-4642-995b-7baa01779a66@loongson.cn/T/#e1d47e2fe185f2e2be8fdc0784f0db2f644119379
Question: Do you have a better name than "addr_global"?
Alternatives:
1. Just use "-mno-explicit-relocs -mla-local-with-abs" for kernel
modules. It's stupid IMO.
2. Implement a "-maddress-local-with-got" option for GCC and use it for
kernel modules. It seems too overkill: we might create many unnecessary
GOT entries.
3. For all variables with a section attribute, consider it global. It
may make sense, but I just checked x86_64 and riscv and they don't do
this.
4. Implement -mcmodel=extreme and use it for kernel modules. To me
"extreme" seems really too extreme.
5. More hacks in kernel. (Convert relocations against .data..percpu with
objtool? But objtool is not even implemented for LoongArch yet.)
Note: I'll be mostly AFK in the following week. My attempt to finish
the kernel support for new relocs before going AFK now failed miserably
:(.
-- >8 --
A linker script and/or a section attribute may locate a local object in
some way unexpected by the code model, leading to a link failure. This
happens when the Linux kernel loads a module with "local" per-CPU
variables.
Add an attribute to explicitly mark an variable with the address
unlimited by the code model so we would be able to work around such
problems.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_attribute_table):
New attribute table.
(TARGET_ATTRIBUTE_TABLE): Define the target hook.
(loongarch_handle_addr_global_attribute): New static function.
(loongarch_classify_symbol): Return SYMBOL_GOT_DISP for
SYMBOL_REF_DECL with addr_global attribute.
* doc/extend.texi (Variable Attributes): Document new
LoongArch specific attribute.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/addr-global.c: New test.
---
gcc/config/loongarch/loongarch.cc | 43 +++++++++++++++++++
gcc/doc/extend.texi | 17 ++++++++
.../gcc.target/loongarch/addr-global.c | 28 ++++++++++++
3 files changed, 88 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/loongarch/addr-global.c
diff --git a/gcc/config/loongarch/loongarch.cc b/gcc/config/loongarch/loongarch.cc
index 79687340dfd..5f4e6114fc9 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1643,6 +1643,13 @@ loongarch_classify_symbol (const_rtx x)
&& !loongarch_symbol_binds_local_p (x))
return SYMBOL_GOT_DISP;
+ if (SYMBOL_REF_P (x))
+ {
+ tree decl = SYMBOL_REF_DECL (x);
+ if (decl && lookup_attribute ("addr_global", DECL_ATTRIBUTES (decl)))
+ return SYMBOL_GOT_DISP;
+ }
+
return SYMBOL_PCREL;
}
@@ -6068,6 +6075,39 @@ loongarch_starting_frame_offset (void)
return crtl->outgoing_args_size;
}
+static tree
+loongarch_handle_addr_global_attribute (tree *node, tree name, tree, int,
+ bool *no_add_attrs)
+{
+ tree decl = *node;
+ if (TREE_CODE (decl) == VAR_DECL)
+ {
+ if (DECL_CONTEXT (decl)
+ && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
+ && !TREE_STATIC (decl))
+ {
+ error_at (DECL_SOURCE_LOCATION (decl),
+ "%qE attribute cannot be specified for local "
+ "variables", name);
+ *no_add_attrs = true;
+ }
+ }
+ else
+ {
+ warning (OPT_Wattributes, "%qE attribute ignored", name);
+ *no_add_attrs = true;
+ }
+ return NULL_TREE;
+}
+
+static const struct attribute_spec loongarch_attribute_table[] =
+{
+ /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
+ affects_type_identity, handler, exclude } */
+ { "addr_global", 0, 0, true, false, false, false,
+ loongarch_handle_addr_global_attribute, NULL }
+};
+
/* Initialize the GCC target structure. */
#undef TARGET_ASM_ALIGNED_HI_OP
#define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
@@ -6256,6 +6296,9 @@ loongarch_starting_frame_offset (void)
#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
+#undef TARGET_ATTRIBUTE_TABLE
+#define TARGET_ATTRIBUTE_TABLE loongarch_attribute_table
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-loongarch.h"
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7fe7f8817cd..4a1cd7ab5e4 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7314,6 +7314,7 @@ attributes.
* Blackfin Variable Attributes::
* H8/300 Variable Attributes::
* IA-64 Variable Attributes::
+* LoongArch Variable Attributes::
* M32R/D Variable Attributes::
* MeP Variable Attributes::
* Microsoft Windows Variable Attributes::
@@ -8098,6 +8099,22 @@ defined by shared libraries.
@end table
+@node LoongArch Variable Attributes
+@subsection LoongArch Variable Attributes
+
+One attribute is currently defined for the LoongArch.
+
+@table @code
+@item addr_global
+@cindex @code{addr_global} variable attribute, LoongArch
+@cindex variable addressability on the LoongArch
+Use this attribute on the LoongArch to mark an object with address
+unlimited limited by the local data section range specified by the code
+model, even if the object is defined locally. This attribute is mostly
+useful if a @code{section} attribute or a linker script will move the
+object somewhere unexpected by the code model.
+@end table
+
@node M32R/D Variable Attributes
@subsection M32R/D Variable Attributes
diff --git a/gcc/testsuite/gcc.target/loongarch/addr-global.c b/gcc/testsuite/gcc.target/loongarch/addr-global.c
new file mode 100644
index 00000000000..d48fa8103a0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/addr-global.c
@@ -0,0 +1,28 @@
+/* addr_global attribute should mark x and y possibly outside of the local
+ data range defined by the code model, so GOT should be used instead of
+ PC-relative. */
+
+/* { dg-do compile } */
+/* { dg-options "-mexplicit-relocs -mcmodel=normal" } */
+/* { dg-final { scan-assembler-not "%pc" } } */
+/* { dg-final { scan-assembler-times "%got_pc_hi20" 3 } } */
+
+static int x __attribute__((addr_global));
+int y __attribute__((addr_global));
+
+int
+test(void)
+{
+ return x + y;
+}
+
+/* The following will be used for kernel per-cpu storage implemention. */
+
+register char *per_cpu_base __asm__("r21");
+static int counter __attribute__((section(".data..percpu"), addr_global));
+void
+inc_counter(void)
+{
+ int *ptr = (int *)(per_cpu_base + (long)&counter);
+ *ptr++;
+}
--
2.37.1
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH v2] LoongArch: add addr_global attribute
2022-07-29 14:22 [PATCH] LoongArch: add addr_global attribute Xi Ruoyao
@ 2022-07-29 15:31 ` Xi Ruoyao
2022-07-29 17:17 ` [PATCH v3] " Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-07-29 15:31 UTC (permalink / raw)
To: gcc-patches, Lulu Cheng
Cc: Youling Tang, xuchenghua, Huacai Chen, Jinyang He, Wang Xuerui
Don't look at V1 patch: I selected wrong file and sent a draft with bugs
mistakenly.
Background:
https://lore.kernel.org/loongarch/d7670b60-2782-4642-995b-7baa01779a66@loongson.cn/T/#e1d47e2fe185f2e2be8fdc0784f0db2f644119379
Question: Do you have a better name than "addr_global"?
Alternatives:
1. Just use "-mno-explicit-relocs -mla-local-with-abs" for kernel
modules. It's stupid IMO.
2. Implement a "-maddress-local-with-got" option for GCC and use it for
kernel modules. It seems too overkill: we might create many unnecessary
GOT entries.
3. For all variables with a section attribute, consider it global. It
may make sense, but I just checked x86_64 and riscv and they don't do
this.
4. Implement -mcmodel=extreme and use it for kernel modules. To me
"extreme" seems really too extreme.
5. More hacks in kernel. (Convert relocations against .data..percpu with
objtool? But objtool is not even implemented for LoongArch yet.)
Note: I'll be mostly AFK in the following week. My attempt to finish
the kernel support for new relocs before going AFK now failed miserably
:(.
-- >8 --
A linker script and/or a section attribute may locate a local object in
some way unexpected by the code model, leading to a link failure. This
happens when the Linux kernel loads a module with "local" per-CPU
variables.
Add an attribute to explicitly mark an variable with the address
unlimited by the code model so we would be able to work around such
problems.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_attribute_table):
New attribute table.
(TARGET_ATTRIBUTE_TABLE): Define the target hook.
(loongarch_handle_addr_global_attribute): New static function.
(loongarch_classify_symbol): Return SYMBOL_GOT_DISP for
SYMBOL_REF_DECL with addr_global attribute.
* doc/extend.texi (Variable Attributes): Document new
LoongArch specific attribute.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/addr-global.c: New test.
---
gcc/config/loongarch/loongarch.cc | 45 +++++++++++++++++++
gcc/doc/extend.texi | 17 +++++++
.../gcc.target/loongarch/addr-global.c | 28 ++++++++++++
3 files changed, 90 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/loongarch/addr-global.c
diff --git a/gcc/config/loongarch/loongarch.cc b/gcc/config/loongarch/loongarch.cc
index 79687340dfd..cdf6bf44e36 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1643,6 +1643,13 @@ loongarch_classify_symbol (const_rtx x)
&& !loongarch_symbol_binds_local_p (x))
return SYMBOL_GOT_DISP;
+ if (SYMBOL_REF_P (x))
+ {
+ tree decl = SYMBOL_REF_DECL (x);
+ if (decl && lookup_attribute ("addr_global", DECL_ATTRIBUTES (decl)))
+ return SYMBOL_GOT_DISP;
+ }
+
return SYMBOL_PCREL;
}
@@ -6068,6 +6075,41 @@ loongarch_starting_frame_offset (void)
return crtl->outgoing_args_size;
}
+static tree
+loongarch_handle_addr_global_attribute (tree *node, tree name, tree, int,
+ bool *no_add_attrs)
+{
+ tree decl = *node;
+ if (TREE_CODE (decl) == VAR_DECL)
+ {
+ if (DECL_CONTEXT (decl)
+ && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
+ && !TREE_STATIC (decl))
+ {
+ error_at (DECL_SOURCE_LOCATION (decl),
+ "%qE attribute cannot be specified for local "
+ "variables", name);
+ *no_add_attrs = true;
+ }
+ }
+ else
+ {
+ warning (OPT_Wattributes, "%qE attribute ignored", name);
+ *no_add_attrs = true;
+ }
+ return NULL_TREE;
+}
+
+static const struct attribute_spec loongarch_attribute_table[] =
+{
+ /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
+ affects_type_identity, handler, exclude } */
+ { "addr_global", 0, 0, true, false, false, false,
+ loongarch_handle_addr_global_attribute, NULL },
+ /* The last attribute spec is set to be NULL. */
+ {}
+};
+
/* Initialize the GCC target structure. */
#undef TARGET_ASM_ALIGNED_HI_OP
#define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
@@ -6256,6 +6298,9 @@ loongarch_starting_frame_offset (void)
#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
+#undef TARGET_ATTRIBUTE_TABLE
+#define TARGET_ATTRIBUTE_TABLE loongarch_attribute_table
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-loongarch.h"
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7fe7f8817cd..4a1cd7ab5e4 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7314,6 +7314,7 @@ attributes.
* Blackfin Variable Attributes::
* H8/300 Variable Attributes::
* IA-64 Variable Attributes::
+* LoongArch Variable Attributes::
* M32R/D Variable Attributes::
* MeP Variable Attributes::
* Microsoft Windows Variable Attributes::
@@ -8098,6 +8099,22 @@ defined by shared libraries.
@end table
+@node LoongArch Variable Attributes
+@subsection LoongArch Variable Attributes
+
+One attribute is currently defined for the LoongArch.
+
+@table @code
+@item addr_global
+@cindex @code{addr_global} variable attribute, LoongArch
+@cindex variable addressability on the LoongArch
+Use this attribute on the LoongArch to mark an object with address
+unlimited limited by the local data section range specified by the code
+model, even if the object is defined locally. This attribute is mostly
+useful if a @code{section} attribute or a linker script will move the
+object somewhere unexpected by the code model.
+@end table
+
@node M32R/D Variable Attributes
@subsection M32R/D Variable Attributes
diff --git a/gcc/testsuite/gcc.target/loongarch/addr-global.c b/gcc/testsuite/gcc.target/loongarch/addr-global.c
new file mode 100644
index 00000000000..0d00d16d420
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/addr-global.c
@@ -0,0 +1,28 @@
+/* addr_global attribute should mark x and y possibly outside of the local
+ data range defined by the code model, so GOT should be used instead of
+ PC-relative. */
+
+/* { dg-do compile } */
+/* { dg-options "-mexplicit-relocs -mcmodel=normal" } */
+/* { dg-final { scan-assembler-not "%pc" } } */
+/* { dg-final { scan-assembler-times "%got_pc_hi20" 3 } } */
+
+static int x __attribute__((addr_global));
+int y __attribute__((addr_global));
+
+int
+test(void)
+{
+ return x + y;
+}
+
+/* The following will be used for kernel per-cpu storage implemention. */
+
+register char *per_cpu_base __asm__("r21");
+static int counter __attribute__((section(".data..percpu"), addr_global));
+void
+inc_counter(void)
+{
+ int *ptr = (int *)(per_cpu_base + (long)&counter);
+ (*ptr)++;
+}
--
2.37.0
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH v3] LoongArch: add addr_global attribute
2022-07-29 15:31 ` [PATCH v2] " Xi Ruoyao
@ 2022-07-29 17:17 ` Xi Ruoyao
2022-07-30 3:13 ` Lulu Cheng
2022-07-31 9:05 ` Chenghua Xu
0 siblings, 2 replies; 29+ messages in thread
From: Xi Ruoyao @ 2022-07-29 17:17 UTC (permalink / raw)
To: gcc-patches, Lulu Cheng
Cc: Jinyang He, xuchenghua, Huacai Chen, Youling Tang, Wang Xuerui
Change v2 to v3:
- Disable section anchor for addr_global symbols.
- Use -O2 in test to make sure section anchor is disabled.
--
Background:
https://lore.kernel.org/loongarch/d7670b60-2782-4642-995b-7baa01779a66@loongson.cn/T/#e1d47e2fe185f2e2be8fdc0784f0db2f644119379
Question: Do you have a better name than "addr_global"?
Alternatives:
1. Just use "-mno-explicit-relocs -mla-local-with-abs" for kernel
modules. It's stupid IMO.
2. Implement a "-maddress-local-with-got" option for GCC and use it for
kernel modules. It seems too overkill: we might create many unnecessary
GOT entries.
3. For all variables with a section attribute, consider it global. It
may make sense, but I just checked x86_64 and riscv and they don't do
this.
4. Implement -mcmodel=extreme and use it for kernel modules. To me
"extreme" seems really too extreme.
5. More hacks in kernel. (Convert relocations against .data..percpu with
objtool? But objtool is not even implemented for LoongArch yet.)
Note: I'll be mostly AFK in the following week. My attempt to finish
the kernel support for new relocs before going AFK now failed miserably
:(.
-- >8 --
A linker script and/or a section attribute may locate a local object in
some way unexpected by the code model, leading to a link failure. This
happens when the Linux kernel loads a module with "local" per-CPU
variables.
Add an attribute to explicitly mark an variable with the address
unlimited by the code model so we would be able to work around such
problems.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_attribute_table):
New attribute table.
(TARGET_ATTRIBUTE_TABLE): Define the target hook.
(loongarch_handle_addr_global_attribute): New static function.
(loongarch_classify_symbol): Return SYMBOL_GOT_DISP for
SYMBOL_REF_DECL with addr_global attribute.
(loongarch_use_anchors_for_symbol_p): New static function.
(TARGET_USE_ANCHORS_FOR_SYMBOL_P): Define the target hook.
* doc/extend.texi (Variable Attributes): Document new
LoongArch specific attribute.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/addr-global.c: New test.
---
gcc/config/loongarch/loongarch.cc | 61 +++++++++++++++++++
gcc/doc/extend.texi | 17 ++++++
.../gcc.target/loongarch/addr-global.c | 28 +++++++++
3 files changed, 106 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/loongarch/addr-global.c
diff --git a/gcc/config/loongarch/loongarch.cc b/gcc/config/loongarch/loongarch.cc
index 79687340dfd..db6f84d4e66 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1643,6 +1643,13 @@ loongarch_classify_symbol (const_rtx x)
&& !loongarch_symbol_binds_local_p (x))
return SYMBOL_GOT_DISP;
+ if (SYMBOL_REF_P (x))
+ {
+ tree decl = SYMBOL_REF_DECL (x);
+ if (decl && lookup_attribute ("addr_global", DECL_ATTRIBUTES (decl)))
+ return SYMBOL_GOT_DISP;
+ }
+
return SYMBOL_PCREL;
}
@@ -6068,6 +6075,54 @@ loongarch_starting_frame_offset (void)
return crtl->outgoing_args_size;
}
+static tree
+loongarch_handle_addr_global_attribute (tree *node, tree name, tree, int,
+ bool *no_add_attrs)
+{
+ tree decl = *node;
+ if (TREE_CODE (decl) == VAR_DECL)
+ {
+ if (DECL_CONTEXT (decl)
+ && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
+ && !TREE_STATIC (decl))
+ {
+ error_at (DECL_SOURCE_LOCATION (decl),
+ "%qE attribute cannot be specified for local "
+ "variables", name);
+ *no_add_attrs = true;
+ }
+ }
+ else
+ {
+ warning (OPT_Wattributes, "%qE attribute ignored", name);
+ *no_add_attrs = true;
+ }
+ return NULL_TREE;
+}
+
+static const struct attribute_spec loongarch_attribute_table[] =
+{
+ /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
+ affects_type_identity, handler, exclude } */
+ { "addr_global", 0, 0, true, false, false, false,
+ loongarch_handle_addr_global_attribute, NULL },
+ /* The last attribute spec is set to be NULL. */
+ {}
+};
+
+bool
+loongarch_use_anchors_for_symbol_p (const_rtx symbol)
+{
+ tree decl = SYMBOL_REF_DECL (symbol);
+
+ /* addr_global indicates we don't know how the linker will locate the symbol,
+ so the use of anchor may cause relocation overflow. */
+ if (decl && lookup_attribute ("addr_global", DECL_ATTRIBUTES (decl)))
+ return false;
+
+ return default_use_anchors_for_symbol_p (symbol);
+}
+
/* Initialize the GCC target structure. */
#undef TARGET_ASM_ALIGNED_HI_OP
#define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
@@ -6256,6 +6311,12 @@ loongarch_starting_frame_offset (void)
#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
+#undef TARGET_ATTRIBUTE_TABLE
+#define TARGET_ATTRIBUTE_TABLE loongarch_attribute_table
+
+#undef TARGET_USE_ANCHORS_FOR_SYMBOL_P
+#define TARGET_USE_ANCHORS_FOR_SYMBOL_P loongarch_use_anchors_for_symbol_p
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-loongarch.h"
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7fe7f8817cd..4a1cd7ab5e4 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7314,6 +7314,7 @@ attributes.
* Blackfin Variable Attributes::
* H8/300 Variable Attributes::
* IA-64 Variable Attributes::
+* LoongArch Variable Attributes::
* M32R/D Variable Attributes::
* MeP Variable Attributes::
* Microsoft Windows Variable Attributes::
@@ -8098,6 +8099,22 @@ defined by shared libraries.
@end table
+@node LoongArch Variable Attributes
+@subsection LoongArch Variable Attributes
+
+One attribute is currently defined for the LoongArch.
+
+@table @code
+@item addr_global
+@cindex @code{addr_global} variable attribute, LoongArch
+@cindex variable addressability on the LoongArch
+Use this attribute on the LoongArch to mark an object with address
+unlimited limited by the local data section range specified by the code
+model, even if the object is defined locally. This attribute is mostly
+useful if a @code{section} attribute or a linker script will move the
+object somewhere unexpected by the code model.
+@end table
+
@node M32R/D Variable Attributes
@subsection M32R/D Variable Attributes
diff --git a/gcc/testsuite/gcc.target/loongarch/addr-global.c b/gcc/testsuite/gcc.target/loongarch/addr-global.c
new file mode 100644
index 00000000000..46a895c84bb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/addr-global.c
@@ -0,0 +1,28 @@
+/* addr_global attribute should mark x and y possibly outside of the local
+ data range defined by the code model, so GOT should be used instead of
+ PC-relative. */
+
+/* { dg-do compile } */
+/* { dg-options "-mexplicit-relocs -mcmodel=normal -O2" } */
+/* { dg-final { scan-assembler-not "%pc" } } */
+/* { dg-final { scan-assembler-times "%got_pc_hi20" 3 } } */
+
+int x __attribute__((addr_global));
+int y __attribute__((addr_global));
+
+int
+test(void)
+{
+ return x + y;
+}
+
+/* The following will be used for kernel per-cpu storage implemention. */
+
+register char *per_cpu_base __asm__("r21");
+static int counter __attribute__((section(".data..percpu"), addr_global));
+void
+inc_counter(void)
+{
+ int *ptr = (int *)(per_cpu_base + (long)&counter);
+ (*ptr)++;
+}
--
2.37.0
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] LoongArch: add addr_global attribute
2022-07-29 17:17 ` [PATCH v3] " Xi Ruoyao
@ 2022-07-30 3:13 ` Lulu Cheng
2022-07-30 6:03 ` Huacai Chen
2022-07-31 9:05 ` Chenghua Xu
1 sibling, 1 reply; 29+ messages in thread
From: Lulu Cheng @ 2022-07-30 3:13 UTC (permalink / raw)
To: Xi Ruoyao, gcc-patches
Cc: Jinyang He, xuchenghua, Huacai Chen, Youling Tang, Wang Xuerui
在 2022/7/30 上午1:17, Xi Ruoyao 写道:
> Change v2 to v3:
> - Disable section anchor for addr_global symbols.
> - Use -O2 in test to make sure section anchor is disabled.
>
> --
>
> Background:
> https://lore.kernel.org/loongarch/d7670b60-2782-4642-995b-7baa01779a66@loongson.cn/T/#e1d47e2fe185f2e2be8fdc0784f0db2f644119379
>
> Question: Do you have a better name than "addr_global"?
I think the name can be changed to "get_through_got".What do you think of it?
>
> Alternatives:
>
> 1. Just use "-mno-explicit-relocs -mla-local-with-abs" for kernel
> modules. It's stupid IMO.
> 2. Implement a "-maddress-local-with-got" option for GCC and use it for
> kernel modules. It seems too overkill: we might create many unnecessary
> GOT entries.
> 3. For all variables with a section attribute, consider it global. It
> may make sense, but I just checked x86_64 and riscv and they don't do
> this.
> 4. Implement -mcmodel=extreme and use it for kernel modules. To me
> "extreme" seems really too extreme.
> 5. More hacks in kernel. (Convert relocations against .data..percpu with
> objtool? But objtool is not even implemented for LoongArch yet.)
>
> Note: I'll be mostly AFK in the following week. My attempt to finish
> the kernel support for new relocs before going AFK now failed miserably
> :(.
>
> -- >8 --
>
> A linker script and/or a section attribute may locate a local object in
> some way unexpected by the code model, leading to a link failure. This
> happens when the Linux kernel loads a module with "local" per-CPU
> variables.
>
> Add an attribute to explicitly mark an variable with the address
> unlimited by the code model so we would be able to work around such
> problems.
>
Others I think are ok.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] LoongArch: add addr_global attribute
2022-07-30 3:13 ` Lulu Cheng
@ 2022-07-30 6:03 ` Huacai Chen
0 siblings, 0 replies; 29+ messages in thread
From: Huacai Chen @ 2022-07-30 6:03 UTC (permalink / raw)
To: Lulu Cheng
Cc: Xi Ruoyao, gcc-patches, Jinyang He, Xu Chenghua, Youling Tang,
Wang Xuerui
Hi, Lulu,
On Sat, Jul 30, 2022 at 11:13 AM Lulu Cheng <chenglulu@loongson.cn> wrote:
>
>
> 在 2022/7/30 上午1:17, Xi Ruoyao 写道:
>
> Change v2 to v3:
> - Disable section anchor for addr_global symbols.
> - Use -O2 in test to make sure section anchor is disabled.
>
> --
>
> Background:
> https://lore.kernel.org/loongarch/d7670b60-2782-4642-995b-7baa01779a66@loongson.cn/T/#e1d47e2fe185f2e2be8fdc0784f0db2f644119379
>
> Question: Do you have a better name than "addr_global"?
>
> I think the name can be changed to "get_through_got". What do you think of it?
Is this the same thing as "movable" once we used internally?
Huacai
>
> Alternatives:
>
> 1. Just use "-mno-explicit-relocs -mla-local-with-abs" for kernel
> modules. It's stupid IMO.
> 2. Implement a "-maddress-local-with-got" option for GCC and use it for
> kernel modules. It seems too overkill: we might create many unnecessary
> GOT entries.
> 3. For all variables with a section attribute, consider it global. It
> may make sense, but I just checked x86_64 and riscv and they don't do
> this.
> 4. Implement -mcmodel=extreme and use it for kernel modules. To me
> "extreme" seems really too extreme.
> 5. More hacks in kernel. (Convert relocations against .data..percpu with
> objtool? But objtool is not even implemented for LoongArch yet.)
>
> Note: I'll be mostly AFK in the following week. My attempt to finish
> the kernel support for new relocs before going AFK now failed miserably
> :(.
>
> -- >8 --
>
> A linker script and/or a section attribute may locate a local object in
> some way unexpected by the code model, leading to a link failure. This
> happens when the Linux kernel loads a module with "local" per-CPU
> variables.
>
> Add an attribute to explicitly mark an variable with the address
> unlimited by the code model so we would be able to work around such
> problems.
>
>
> Others I think are ok.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] LoongArch: add addr_global attribute
2022-07-29 17:17 ` [PATCH v3] " Xi Ruoyao
2022-07-30 3:13 ` Lulu Cheng
@ 2022-07-31 9:05 ` Chenghua Xu
2022-08-01 10:04 ` [PATCH v4] LoongArch: add movable attribute Xi Ruoyao
1 sibling, 1 reply; 29+ messages in thread
From: Chenghua Xu @ 2022-07-31 9:05 UTC (permalink / raw)
To: Xi Ruoyao, gcc-patches, Lulu Cheng
Cc: Youling Tang, Huacai Chen, Jinyang He, Wang Xuerui
在 2022/7/30 上午1:17, Xi Ruoyao via Gcc-patches 写道:
> Change v2 to v3:
> - Disable section anchor for addr_global symbols.
> - Use -O2 in test to make sure section anchor is disabled.
>
> --
>
> Background:
> https://lore.kernel.org/loongarch/d7670b60-2782-4642-995b-7baa01779a66@loongson.cn/T/#e1d47e2fe185f2e2be8fdc0784f0db2f644119379
>
> Question: Do you have a better name than "addr_global"?
>
> Alternatives:
>
> 1. Just use "-mno-explicit-relocs -mla-local-with-abs" for kernel
> modules. It's stupid IMO.
> 2. Implement a "-maddress-local-with-got" option for GCC and use it for
> kernel modules. It seems too overkill: we might create many unnecessary
> GOT entries.
> 3. For all variables with a section attribute, consider it global. It
> may make sense, but I just checked x86_64 and riscv and they don't do
> this.
> 4. Implement -mcmodel=extreme and use it for kernel modules. To me
> "extreme" seems really too extreme.
> 5. More hacks in kernel. (Convert relocations against .data..percpu with
> objtool? But objtool is not even implemented for LoongArch yet.)
>
> Note: I'll be mostly AFK in the following week. My attempt to finish
> the kernel support for new relocs before going AFK now failed miserably
> :(.
>
> -- >8 --
>
> A linker script and/or a section attribute may locate a local object in
> some way unexpected by the code model, leading to a link failure. This
> happens when the Linux kernel loads a module with "local" per-CPU
> variables.
>
> Add an attribute to explicitly mark an variable with the address
> unlimited by the code model so we would be able to work around such
> problems.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.cc (loongarch_attribute_table):
> New attribute table.
> (TARGET_ATTRIBUTE_TABLE): Define the target hook.
> (loongarch_handle_addr_global_attribute): New static function.
> (loongarch_classify_symbol): Return SYMBOL_GOT_DISP for
> SYMBOL_REF_DECL with addr_global attribute.
> (loongarch_use_anchors_for_symbol_p): New static function.
> (TARGET_USE_ANCHORS_FOR_SYMBOL_P): Define the target hook.
> * doc/extend.texi (Variable Attributes): Document new
> LoongArch specific attribute.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/loongarch/addr-global.c: New test.
> ---
> gcc/config/loongarch/loongarch.cc | 61 +++++++++++++++++++
> gcc/doc/extend.texi | 17 ++++++
> .../gcc.target/loongarch/addr-global.c | 28 +++++++++
> 3 files changed, 106 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/loongarch/addr-global.c
>
> diff --git a/gcc/config/loongarch/loongarch.cc b/gcc/config/loongarch/loongarch.cc
> index 79687340dfd..db6f84d4e66 100644
> --- a/gcc/config/loongarch/loongarch.cc
> +++ b/gcc/config/loongarch/loongarch.cc
> @@ -1643,6 +1643,13 @@ loongarch_classify_symbol (const_rtx x)
> && !loongarch_symbol_binds_local_p (x))
> return SYMBOL_GOT_DISP;
>
> + if (SYMBOL_REF_P (x))
> + {
> + tree decl = SYMBOL_REF_DECL (x);
> + if (decl && lookup_attribute ("addr_global", DECL_ATTRIBUTES (decl)))
> + return SYMBOL_GOT_DISP;
> + }
> +
> return SYMBOL_PCREL;
> }
>
> @@ -6068,6 +6075,54 @@ loongarch_starting_frame_offset (void)
> return crtl->outgoing_args_size;
> }
>
> +static tree
> +loongarch_handle_addr_global_attribute (tree *node, tree name, tree, int,
> + bool *no_add_attrs)
> +{
> + tree decl = *node;
> + if (TREE_CODE (decl) == VAR_DECL)
> + {
> + if (DECL_CONTEXT (decl)
> + && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
> + && !TREE_STATIC (decl))
> + {
> + error_at (DECL_SOURCE_LOCATION (decl),
> + "%qE attribute cannot be specified for local "
> + "variables", name);
> + *no_add_attrs = true;
> + }
> + }
> + else
> + {
> + warning (OPT_Wattributes, "%qE attribute ignored", name);
> + *no_add_attrs = true;
> + }
> + return NULL_TREE;
> +}
> +
> +static const struct attribute_spec loongarch_attribute_table[] =
> +{
> + /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
> + affects_type_identity, handler, exclude } */
> + { "addr_global", 0, 0, true, false, false, false,
> + loongarch_handle_addr_global_attribute, NULL },
> + /* The last attribute spec is set to be NULL. */
> + {}
> +};
> +
> +bool
> +loongarch_use_anchors_for_symbol_p (const_rtx symbol)
> +{
> + tree decl = SYMBOL_REF_DECL (symbol);
> +
> + /* addr_global indicates we don't know how the linker will locate the symbol,
> + so the use of anchor may cause relocation overflow. */
> + if (decl && lookup_attribute ("addr_global", DECL_ATTRIBUTES (decl)))
> + return false;
> +
> + return default_use_anchors_for_symbol_p (symbol);
> +}
> +
> /* Initialize the GCC target structure. */
> #undef TARGET_ASM_ALIGNED_HI_OP
> #define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
> @@ -6256,6 +6311,12 @@ loongarch_starting_frame_offset (void)
> #undef TARGET_HAVE_SPECULATION_SAFE_VALUE
> #define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
>
> +#undef TARGET_ATTRIBUTE_TABLE
> +#define TARGET_ATTRIBUTE_TABLE loongarch_attribute_table
> +
> +#undef TARGET_USE_ANCHORS_FOR_SYMBOL_P
> +#define TARGET_USE_ANCHORS_FOR_SYMBOL_P loongarch_use_anchors_for_symbol_p
> +
> struct gcc_target targetm = TARGET_INITIALIZER;
>
> #include "gt-loongarch.h"
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 7fe7f8817cd..4a1cd7ab5e4 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -7314,6 +7314,7 @@ attributes.
> * Blackfin Variable Attributes::
> * H8/300 Variable Attributes::
> * IA-64 Variable Attributes::
> +* LoongArch Variable Attributes::
> * M32R/D Variable Attributes::
> * MeP Variable Attributes::
> * Microsoft Windows Variable Attributes::
> @@ -8098,6 +8099,22 @@ defined by shared libraries.
>
> @end table
>
> +@node LoongArch Variable Attributes
> +@subsection LoongArch Variable Attributes
> +
> +One attribute is currently defined for the LoongArch.
> +
> +@table @code
> +@item addr_global
> +@cindex @code{addr_global} variable attribute, LoongArch
> +@cindex variable addressability on the LoongArch
Can't understand this, Copied and forget to changing?
> +Use this attribute on the LoongArch to mark an object with address
> +unlimited limited by the local data section range specified by the code
> +model, even if the object is defined locally. This attribute is mostly
> +useful if a @code{section} attribute or a linker script will move the
> +object somewhere unexpected by the code model.
> +@end table
> +
> @node M32R/D Variable Attributes
> @subsection M32R/D Variable Attributes
>
> diff --git a/gcc/testsuite/gcc.target/loongarch/addr-global.c b/gcc/testsuite/gcc.target/loongarch/addr-global.c
> new file mode 100644
> index 00000000000..46a895c84bb
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/addr-global.c
> @@ -0,0 +1,28 @@
> +/* addr_global attribute should mark x and y possibly outside of the local
> + data range defined by the code model, so GOT should be used instead of
> + PC-relative. */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-mexplicit-relocs -mcmodel=normal -O2" } */
> +/* { dg-final { scan-assembler-not "%pc" } } */
> +/* { dg-final { scan-assembler-times "%got_pc_hi20" 3 } } */
> +
> +int x __attribute__((addr_global));
> +int y __attribute__((addr_global));
> +
> +int
> +test(void)
> +{
> + return x + y;
> +}
> +
> +/* The following will be used for kernel per-cpu storage implemention. */
> +
> +register char *per_cpu_base __asm__("r21");
> +static int counter __attribute__((section(".data..percpu"), addr_global));
> +void
> +inc_counter(void)
> +{
> + int *ptr = (int *)(per_cpu_base + (long)&counter);
> + (*ptr)++;
> +}
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH v4] LoongArch: add movable attribute
2022-07-31 9:05 ` Chenghua Xu
@ 2022-08-01 10:04 ` Xi Ruoyao
2022-08-01 10:07 ` [PATCH v5] " Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-01 10:04 UTC (permalink / raw)
To: Chenghua Xu, gcc-patches, Lulu Cheng
Cc: Youling Tang, Huacai Chen, Jinyang He, Wang Xuerui
Changes v3 -> v4:
* Use "movable" as the attribute name as Huacai says it's already used
in downstream GCC fork.
* Remove an inaccurate line from the doc. (Initially I tried to
implement a "model(...)" like IA64 or M32R. Then I changed my mind
but forgot to remove the line copied from M32R doc.)
-- >8 --
A linker script and/or a section attribute may locate a local object in
some way unexpected by the code model, leading to a link failure. This
happens when the Linux kernel loads a module with "local" per-CPU
variables.
Add an attribute to explicitly mark an variable with the address
unlimited by the code model so we would be able to work around such
problems.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_attribute_table):
New attribute table.
(TARGET_ATTRIBUTE_TABLE): Define the target hook.
(loongarch_handle_addr_global_attribute): New static function.
(loongarch_classify_symbol): Return SYMBOL_GOT_DISP for
SYMBOL_REF_DECL with addr_global attribute.
(loongarch_use_anchors_for_symbol_p): New static function.
(TARGET_USE_ANCHORS_FOR_SYMBOL_P): Define the target hook.
* doc/extend.texi (Variable Attributes): Document new
LoongArch specific attribute.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/addr-global.c: New test.
---
gcc/config/loongarch/loongarch.cc | 63 +++++++++++++++++++
gcc/doc/extend.texi | 16 +++++
.../gcc.target/loongarch/attr-movable.c | 29 +++++++++
3 files changed, 108 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/loongarch/attr-movable.c
diff --git a/gcc/config/loongarch/loongarch.cc b/gcc/config/loongarch/loongarch.cc
index 79687340dfd..6b6026700a6 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1643,6 +1643,15 @@ loongarch_classify_symbol (const_rtx x)
&& !loongarch_symbol_binds_local_p (x))
return SYMBOL_GOT_DISP;
+ if (SYMBOL_REF_P (x))
+ {
+ tree decl = SYMBOL_REF_DECL (x);
+ /* A movable symbol may be moved away from the +/- 2GiB range around
+ the PC, so we have to use GOT. */
+ if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES (decl)))
+ return SYMBOL_GOT_DISP;
+ }
+
return SYMBOL_PCREL;
}
@@ -6068,6 +6077,54 @@ loongarch_starting_frame_offset (void)
return crtl->outgoing_args_size;
}
+static tree
+loongarch_handle_movable_attribute (tree *node, tree name, tree, int,
+ bool *no_add_attrs)
+{
+ tree decl = *node;
+ if (TREE_CODE (decl) == VAR_DECL)
+ {
+ if (DECL_CONTEXT (decl)
+ && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
+ && !TREE_STATIC (decl))
+ {
+ error_at (DECL_SOURCE_LOCATION (decl),
+ "%qE attribute cannot be specified for local "
+ "variables", name);
+ *no_add_attrs = true;
+ }
+ }
+ else
+ {
+ warning (OPT_Wattributes, "%qE attribute ignored", name);
+ *no_add_attrs = true;
+ }
+ return NULL_TREE;
+}
+
+static const struct attribute_spec loongarch_attribute_table[] =
+{
+ /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
+ affects_type_identity, handler, exclude } */
+ { "movable", 0, 0, true, false, false, false,
+ loongarch_handle_movable_attribute, NULL },
+ /* The last attribute spec is set to be NULL. */
+ {}
+};
+
+bool
+loongarch_use_anchors_for_symbol_p (const_rtx symbol)
+{
+ tree decl = SYMBOL_REF_DECL (symbol);
+
+ /* A movable attribute indicates the linker may move the symbol away,
+ so the use of anchor may cause relocation overflow. */
+ if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES (decl)))
+ return false;
+
+ return default_use_anchors_for_symbol_p (symbol);
+}
+
/* Initialize the GCC target structure. */
#undef TARGET_ASM_ALIGNED_HI_OP
#define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
@@ -6256,6 +6313,12 @@ loongarch_starting_frame_offset (void)
#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
+#undef TARGET_ATTRIBUTE_TABLE
+#define TARGET_ATTRIBUTE_TABLE loongarch_attribute_table
+
+#undef TARGET_USE_ANCHORS_FOR_SYMBOL_P
+#define TARGET_USE_ANCHORS_FOR_SYMBOL_P loongarch_use_anchors_for_symbol_p
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-loongarch.h"
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7fe7f8817cd..322d8c05a04 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7314,6 +7314,7 @@ attributes.
* Blackfin Variable Attributes::
* H8/300 Variable Attributes::
* IA-64 Variable Attributes::
+* LoongArch Variable Attributes::
* M32R/D Variable Attributes::
* MeP Variable Attributes::
* Microsoft Windows Variable Attributes::
@@ -8098,6 +8099,21 @@ defined by shared libraries.
@end table
+@node LoongArch Variable Attributes
+@subsection LoongArch Variable Attributes
+
+One attribute is currently defined for the LoongArch.
+
+@table @code
+@item movable
+@cindex @code{movable} variable attribute, LoongArch
+Use this attribute on the LoongArch to mark an object possible to be moved
+by the linker, so its address is unlimited by the local data section range
+specified by the code model even if the object is defined locally. This
+attribute is mostly useful if a @code{section} attribute and/or a linker
+script will move the object somewhere unexpected by the code model.
+@end table
+
@node M32R/D Variable Attributes
@subsection M32R/D Variable Attributes
diff --git a/gcc/testsuite/gcc.target/loongarch/attr-movable.c b/gcc/testsuite/gcc.target/loongarch/attr-movable.c
new file mode 100644
index 00000000000..85b1dd4c59a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/attr-movable.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-mexplicit-relocs -mcmodel=normal -O2" } */
+/* { dg-final { scan-assembler-not "%pc" } } */
+/* { dg-final { scan-assembler-times "%got_pc_hi20" 3 } } */
+
+/* movable attribute should mark x and y possibly outside of the local
+ data range defined by the code model, so GOT should be used instead of
+ PC-relative. */
+
+int x __attribute__((movable));
+int y __attribute__((movable));
+
+int
+test(void)
+{
+ return x + y;
+}
+
+/* The following will be used for kernel per-cpu storage implemention. */
+
+register char *per_cpu_base __asm__("r21");
+static int counter __attribute__((section(".data..percpu"), movable));
+
+void
+inc_counter(void)
+{
+ int *ptr = (int *)(per_cpu_base + (long)&counter);
+ (*ptr)++;
+}
--
2.37.1
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH v5] LoongArch: add movable attribute
2022-08-01 10:04 ` [PATCH v4] LoongArch: add movable attribute Xi Ruoyao
@ 2022-08-01 10:07 ` Xi Ruoyao
2022-08-03 1:36 ` Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-01 10:07 UTC (permalink / raw)
To: Chenghua Xu, gcc-patches, Lulu Cheng
Cc: Jinyang He, Huacai Chen, Youling Tang, Wang Xuerui
Changes v4 -> v5: Fix changelog. No code change.
Changes v3 -> v4:
* Use "movable" as the attribute name as Huacai says it's already used
in downstream GCC fork.
* Remove an inaccurate line from the doc. (Initially I tried to
implement a "model(...)" like IA64 or M32R. Then I changed my mind
but forgot to remove the line copied from M32R doc.)
-- >8 --
A linker script and/or a section attribute may locate a local object in
some way unexpected by the code model, leading to a link failure. This
happens when the Linux kernel loads a module with "local" per-CPU
variables.
Add an attribute to explicitly mark an variable with the address
unlimited by the code model so we would be able to work around such
problems.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_attribute_table):
New attribute table.
(TARGET_ATTRIBUTE_TABLE): Define the target hook.
(loongarch_handle_addr_global_attribute): New static function.
(loongarch_classify_symbol): Return SYMBOL_GOT_DISP for
SYMBOL_REF_DECL with addr_global attribute.
(loongarch_use_anchors_for_symbol_p): New static function.
(TARGET_USE_ANCHORS_FOR_SYMBOL_P): Define the target hook.
* doc/extend.texi (Variable Attributes): Document new
LoongArch specific attribute.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/addr-global.c: New test.
---
gcc/config/loongarch/loongarch.cc | 63 +++++++++++++++++++
gcc/doc/extend.texi | 16 +++++
.../gcc.target/loongarch/attr-movable.c | 29 +++++++++
3 files changed, 108 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/loongarch/attr-movable.c
diff --git a/gcc/config/loongarch/loongarch.cc b/gcc/config/loongarch/loongarch.cc
index 79687340dfd..6b6026700a6 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1643,6 +1643,15 @@ loongarch_classify_symbol (const_rtx x)
&& !loongarch_symbol_binds_local_p (x))
return SYMBOL_GOT_DISP;
+ if (SYMBOL_REF_P (x))
+ {
+ tree decl = SYMBOL_REF_DECL (x);
+ /* A movable symbol may be moved away from the +/- 2GiB range around
+ the PC, so we have to use GOT. */
+ if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES (decl)))
+ return SYMBOL_GOT_DISP;
+ }
+
return SYMBOL_PCREL;
}
@@ -6068,6 +6077,54 @@ loongarch_starting_frame_offset (void)
return crtl->outgoing_args_size;
}
+static tree
+loongarch_handle_movable_attribute (tree *node, tree name, tree, int,
+ bool *no_add_attrs)
+{
+ tree decl = *node;
+ if (TREE_CODE (decl) == VAR_DECL)
+ {
+ if (DECL_CONTEXT (decl)
+ && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
+ && !TREE_STATIC (decl))
+ {
+ error_at (DECL_SOURCE_LOCATION (decl),
+ "%qE attribute cannot be specified for local "
+ "variables", name);
+ *no_add_attrs = true;
+ }
+ }
+ else
+ {
+ warning (OPT_Wattributes, "%qE attribute ignored", name);
+ *no_add_attrs = true;
+ }
+ return NULL_TREE;
+}
+
+static const struct attribute_spec loongarch_attribute_table[] =
+{
+ /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
+ affects_type_identity, handler, exclude } */
+ { "movable", 0, 0, true, false, false, false,
+ loongarch_handle_movable_attribute, NULL },
+ /* The last attribute spec is set to be NULL. */
+ {}
+};
+
+bool
+loongarch_use_anchors_for_symbol_p (const_rtx symbol)
+{
+ tree decl = SYMBOL_REF_DECL (symbol);
+
+ /* A movable attribute indicates the linker may move the symbol away,
+ so the use of anchor may cause relocation overflow. */
+ if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES (decl)))
+ return false;
+
+ return default_use_anchors_for_symbol_p (symbol);
+}
+
/* Initialize the GCC target structure. */
#undef TARGET_ASM_ALIGNED_HI_OP
#define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
@@ -6256,6 +6313,12 @@ loongarch_starting_frame_offset (void)
#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
+#undef TARGET_ATTRIBUTE_TABLE
+#define TARGET_ATTRIBUTE_TABLE loongarch_attribute_table
+
+#undef TARGET_USE_ANCHORS_FOR_SYMBOL_P
+#define TARGET_USE_ANCHORS_FOR_SYMBOL_P loongarch_use_anchors_for_symbol_p
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-loongarch.h"
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7fe7f8817cd..322d8c05a04 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7314,6 +7314,7 @@ attributes.
* Blackfin Variable Attributes::
* H8/300 Variable Attributes::
* IA-64 Variable Attributes::
+* LoongArch Variable Attributes::
* M32R/D Variable Attributes::
* MeP Variable Attributes::
* Microsoft Windows Variable Attributes::
@@ -8098,6 +8099,21 @@ defined by shared libraries.
@end table
+@node LoongArch Variable Attributes
+@subsection LoongArch Variable Attributes
+
+One attribute is currently defined for the LoongArch.
+
+@table @code
+@item movable
+@cindex @code{movable} variable attribute, LoongArch
+Use this attribute on the LoongArch to mark an object possible to be moved
+by the linker, so its address is unlimited by the local data section range
+specified by the code model even if the object is defined locally. This
+attribute is mostly useful if a @code{section} attribute and/or a linker
+script will move the object somewhere unexpected by the code model.
+@end table
+
@node M32R/D Variable Attributes
@subsection M32R/D Variable Attributes
diff --git a/gcc/testsuite/gcc.target/loongarch/attr-movable.c b/gcc/testsuite/gcc.target/loongarch/attr-movable.c
new file mode 100644
index 00000000000..85b1dd4c59a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/attr-movable.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-mexplicit-relocs -mcmodel=normal -O2" } */
+/* { dg-final { scan-assembler-not "%pc" } } */
+/* { dg-final { scan-assembler-times "%got_pc_hi20" 3 } } */
+
+/* movable attribute should mark x and y possibly outside of the local
+ data range defined by the code model, so GOT should be used instead of
+ PC-relative. */
+
+int x __attribute__((movable));
+int y __attribute__((movable));
+
+int
+test(void)
+{
+ return x + y;
+}
+
+/* The following will be used for kernel per-cpu storage implemention. */
+
+register char *per_cpu_base __asm__("r21");
+static int counter __attribute__((section(".data..percpu"), movable));
+
+void
+inc_counter(void)
+{
+ int *ptr = (int *)(per_cpu_base + (long)&counter);
+ (*ptr)++;
+}
--
2.37.1
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v5] LoongArch: add movable attribute
2022-08-01 10:07 ` [PATCH v5] " Xi Ruoyao
@ 2022-08-03 1:36 ` Xi Ruoyao
2022-08-03 2:59 ` WANG Xuerui
[not found] ` <-2muj1c-68saz6jhkcyw3jo1xp-1mgcvnkbqi2wjp6tue-qsso54-emxgu3-k85590-kpgox7-w67u6h3cai1l-5bi887dsgzsu-g4d7i7-wl316qxrucx4kv4on7-mnna36-iremg8-nwc5ot-9041t2-hu8nsl.1659495047941@email.android.com>
0 siblings, 2 replies; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-03 1:36 UTC (permalink / raw)
To: Chenghua Xu, gcc-patches, Lulu Cheng
Cc: Jinyang He, Huacai Chen, Youling Tang, Wang Xuerui
Is it OK for trunk or I need to change something?
By the way, I'm seeking a possibility to include this into 12.2. Then
we leaves only 12.1 without this attribute, and we can just say
"building the kernel needs GCC 12.2 or later".
On Mon, 2022-08-01 at 18:07 +0800, Xi Ruoyao wrote:
> Changes v4 -> v5: Fix changelog. No code change.
>
> Changes v3 -> v4:
>
> * Use "movable" as the attribute name as Huacai says it's already
> used
> in downstream GCC fork.
> * Remove an inaccurate line from the doc. (Initially I tried to
> implement a "model(...)" like IA64 or M32R. Then I changed my mind
> but forgot to remove the line copied from M32R doc.)
>
> -- >8 --
>
> A linker script and/or a section attribute may locate a local object
> in
> some way unexpected by the code model, leading to a link failure.
> This
> happens when the Linux kernel loads a module with "local" per-CPU
> variables.
>
> Add an attribute to explicitly mark an variable with the address
> unlimited by the code model so we would be able to work around such
> problems.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.cc (loongarch_attribute_table):
> New attribute table.
> (TARGET_ATTRIBUTE_TABLE): Define the target hook.
> (loongarch_handle_addr_global_attribute): New static function.
> (loongarch_classify_symbol): Return SYMBOL_GOT_DISP for
> SYMBOL_REF_DECL with addr_global attribute.
> (loongarch_use_anchors_for_symbol_p): New static function.
> (TARGET_USE_ANCHORS_FOR_SYMBOL_P): Define the target hook.
> * doc/extend.texi (Variable Attributes): Document new
> LoongArch specific attribute.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/loongarch/addr-global.c: New test.
> ---
> gcc/config/loongarch/loongarch.cc | 63
> +++++++++++++++++++
> gcc/doc/extend.texi | 16 +++++
> .../gcc.target/loongarch/attr-movable.c | 29 +++++++++
> 3 files changed, 108 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/loongarch/attr-movable.c
>
> diff --git a/gcc/config/loongarch/loongarch.cc
> b/gcc/config/loongarch/loongarch.cc
> index 79687340dfd..6b6026700a6 100644
> --- a/gcc/config/loongarch/loongarch.cc
> +++ b/gcc/config/loongarch/loongarch.cc
> @@ -1643,6 +1643,15 @@ loongarch_classify_symbol (const_rtx x)
> && !loongarch_symbol_binds_local_p (x))
> return SYMBOL_GOT_DISP;
>
> + if (SYMBOL_REF_P (x))
> + {
> + tree decl = SYMBOL_REF_DECL (x);
> + /* A movable symbol may be moved away from the +/- 2GiB range
> around
> + the PC, so we have to use GOT. */
> + if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES
> (decl)))
> + return SYMBOL_GOT_DISP;
> + }
> +
> return SYMBOL_PCREL;
> }
>
> @@ -6068,6 +6077,54 @@ loongarch_starting_frame_offset (void)
> return crtl->outgoing_args_size;
> }
>
> +static tree
> +loongarch_handle_movable_attribute (tree *node, tree name, tree, int,
> + bool *no_add_attrs)
> +{
> + tree decl = *node;
> + if (TREE_CODE (decl) == VAR_DECL)
> + {
> + if (DECL_CONTEXT (decl)
> + && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
> + && !TREE_STATIC (decl))
> + {
> + error_at (DECL_SOURCE_LOCATION (decl),
> + "%qE attribute cannot be specified for local "
> + "variables", name);
> + *no_add_attrs = true;
> + }
> + }
> + else
> + {
> + warning (OPT_Wattributes, "%qE attribute ignored", name);
> + *no_add_attrs = true;
> + }
> + return NULL_TREE;
> +}
> +
> +static const struct attribute_spec loongarch_attribute_table[] =
> +{
> + /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
> + affects_type_identity, handler, exclude } */
> + { "movable", 0, 0, true, false, false, false,
> + loongarch_handle_movable_attribute, NULL },
> + /* The last attribute spec is set to be NULL. */
> + {}
> +};
> +
> +bool
> +loongarch_use_anchors_for_symbol_p (const_rtx symbol)
> +{
> + tree decl = SYMBOL_REF_DECL (symbol);
> +
> + /* A movable attribute indicates the linker may move the symbol
> away,
> + so the use of anchor may cause relocation overflow. */
> + if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES (decl)))
> + return false;
> +
> + return default_use_anchors_for_symbol_p (symbol);
> +}
> +
> /* Initialize the GCC target structure. */
> #undef TARGET_ASM_ALIGNED_HI_OP
> #define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
> @@ -6256,6 +6313,12 @@ loongarch_starting_frame_offset (void)
> #undef TARGET_HAVE_SPECULATION_SAFE_VALUE
> #define TARGET_HAVE_SPECULATION_SAFE_VALUE
> speculation_safe_value_not_needed
>
> +#undef TARGET_ATTRIBUTE_TABLE
> +#define TARGET_ATTRIBUTE_TABLE loongarch_attribute_table
> +
> +#undef TARGET_USE_ANCHORS_FOR_SYMBOL_P
> +#define TARGET_USE_ANCHORS_FOR_SYMBOL_P
> loongarch_use_anchors_for_symbol_p
> +
> struct gcc_target targetm = TARGET_INITIALIZER;
>
> #include "gt-loongarch.h"
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 7fe7f8817cd..322d8c05a04 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -7314,6 +7314,7 @@ attributes.
> * Blackfin Variable Attributes::
> * H8/300 Variable Attributes::
> * IA-64 Variable Attributes::
> +* LoongArch Variable Attributes::
> * M32R/D Variable Attributes::
> * MeP Variable Attributes::
> * Microsoft Windows Variable Attributes::
> @@ -8098,6 +8099,21 @@ defined by shared libraries.
>
> @end table
>
> +@node LoongArch Variable Attributes
> +@subsection LoongArch Variable Attributes
> +
> +One attribute is currently defined for the LoongArch.
> +
> +@table @code
> +@item movable
> +@cindex @code{movable} variable attribute, LoongArch
> +Use this attribute on the LoongArch to mark an object possible to be
> moved
> +by the linker, so its address is unlimited by the local data section
> range
> +specified by the code model even if the object is defined locally.
> This
> +attribute is mostly useful if a @code{section} attribute and/or a
> linker
> +script will move the object somewhere unexpected by the code model.
> +@end table
> +
> @node M32R/D Variable Attributes
> @subsection M32R/D Variable Attributes
>
> diff --git a/gcc/testsuite/gcc.target/loongarch/attr-movable.c
> b/gcc/testsuite/gcc.target/loongarch/attr-movable.c
> new file mode 100644
> index 00000000000..85b1dd4c59a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/attr-movable.c
> @@ -0,0 +1,29 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mexplicit-relocs -mcmodel=normal -O2" } */
> +/* { dg-final { scan-assembler-not "%pc" } } */
> +/* { dg-final { scan-assembler-times "%got_pc_hi20" 3 } } */
> +
> +/* movable attribute should mark x and y possibly outside of the
> local
> + data range defined by the code model, so GOT should be used
> instead of
> + PC-relative. */
> +
> +int x __attribute__((movable));
> +int y __attribute__((movable));
> +
> +int
> +test(void)
> +{
> + return x + y;
> +}
> +
> +/* The following will be used for kernel per-cpu storage
> implemention. */
> +
> +register char *per_cpu_base __asm__("r21");
> +static int counter __attribute__((section(".data..percpu"),
> movable));
> +
> +void
> +inc_counter(void)
> +{
> + int *ptr = (int *)(per_cpu_base + (long)&counter);
> + (*ptr)++;
> +}
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v5] LoongArch: add movable attribute
2022-08-03 1:36 ` Xi Ruoyao
@ 2022-08-03 2:59 ` WANG Xuerui
2022-08-03 3:15 ` Xi Ruoyao
[not found] ` <-2muj1c-68saz6jhkcyw3jo1xp-1mgcvnkbqi2wjp6tue-qsso54-emxgu3-k85590-kpgox7-w67u6h3cai1l-5bi887dsgzsu-g4d7i7-wl316qxrucx4kv4on7-mnna36-iremg8-nwc5ot-9041t2-hu8nsl.1659495047941@email.android.com>
1 sibling, 1 reply; 29+ messages in thread
From: WANG Xuerui @ 2022-08-03 2:59 UTC (permalink / raw)
To: Xi Ruoyao, Chenghua Xu, gcc-patches, Lulu Cheng
Cc: Jinyang He, Huacai Chen, Youling Tang
On 2022/8/3 09:36, Xi Ruoyao wrote:
> Is it OK for trunk or I need to change something?
>
> By the way, I'm seeking a possibility to include this into 12.2. Then
> we leaves only 12.1 without this attribute, and we can just say
> "building the kernel needs GCC 12.2 or later".
>
> On Mon, 2022-08-01 at 18:07 +0800, Xi Ruoyao wrote:
>> Changes v4 -> v5: Fix changelog. No code change.
>>
>> Changes v3 -> v4:
>>
>> * Use "movable" as the attribute name as Huacai says it's already
>> used
>> in downstream GCC fork.
I don't think mindlessly caring for vendor forks is always correct. In
fact I find the name "movable" too generic, and something like
"force_got_access" could be better.
I don't currently have time to test this, unfortunately, due to day job.
Might be able to give it a whirl one or two week later though...
>> * Remove an inaccurate line from the doc. (Initially I tried to
>> implement a "model(...)" like IA64 or M32R. Then I changed my mind
>> but forgot to remove the line copied from M32R doc.)
>>
>> -- >8 --
>>
>> A linker script and/or a section attribute may locate a local object
>> in
>> some way unexpected by the code model, leading to a link failure.
>> This
>> happens when the Linux kernel loads a module with "local" per-CPU
>> variables.
>>
>> Add an attribute to explicitly mark an variable with the address
>> unlimited by the code model so we would be able to work around such
>> problems.
>>
>> gcc/ChangeLog:
>>
>> * config/loongarch/loongarch.cc (loongarch_attribute_table):
>> New attribute table.
>> (TARGET_ATTRIBUTE_TABLE): Define the target hook.
>> (loongarch_handle_addr_global_attribute): New static function.
>> (loongarch_classify_symbol): Return SYMBOL_GOT_DISP for
>> SYMBOL_REF_DECL with addr_global attribute.
>> (loongarch_use_anchors_for_symbol_p): New static function.
>> (TARGET_USE_ANCHORS_FOR_SYMBOL_P): Define the target hook.
>> * doc/extend.texi (Variable Attributes): Document new
>> LoongArch specific attribute.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/loongarch/addr-global.c: New test.
>> ---
>> gcc/config/loongarch/loongarch.cc | 63
>> +++++++++++++++++++
>> gcc/doc/extend.texi | 16 +++++
>> .../gcc.target/loongarch/attr-movable.c | 29 +++++++++
>> 3 files changed, 108 insertions(+)
>> create mode 100644 gcc/testsuite/gcc.target/loongarch/attr-movable.c
>>
>> diff --git a/gcc/config/loongarch/loongarch.cc
>> b/gcc/config/loongarch/loongarch.cc
>> index 79687340dfd..6b6026700a6 100644
>> --- a/gcc/config/loongarch/loongarch.cc
>> +++ b/gcc/config/loongarch/loongarch.cc
>> @@ -1643,6 +1643,15 @@ loongarch_classify_symbol (const_rtx x)
>> && !loongarch_symbol_binds_local_p (x))
>> return SYMBOL_GOT_DISP;
>>
>> + if (SYMBOL_REF_P (x))
>> + {
>> + tree decl = SYMBOL_REF_DECL (x);
>> + /* A movable symbol may be moved away from the +/- 2GiB range
>> around
>> + the PC, so we have to use GOT. */
>> + if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES
>> (decl)))
>> + return SYMBOL_GOT_DISP;
>> + }
>> +
>> return SYMBOL_PCREL;
>> }
>>
>> @@ -6068,6 +6077,54 @@ loongarch_starting_frame_offset (void)
>> return crtl->outgoing_args_size;
>> }
>>
>> +static tree
>> +loongarch_handle_movable_attribute (tree *node, tree name, tree, int,
>> + bool *no_add_attrs)
>> +{
>> + tree decl = *node;
>> + if (TREE_CODE (decl) == VAR_DECL)
>> + {
>> + if (DECL_CONTEXT (decl)
>> + && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
>> + && !TREE_STATIC (decl))
>> + {
>> + error_at (DECL_SOURCE_LOCATION (decl),
>> + "%qE attribute cannot be specified for local "
>> + "variables", name);
>> + *no_add_attrs = true;
>> + }
>> + }
>> + else
>> + {
>> + warning (OPT_Wattributes, "%qE attribute ignored", name);
>> + *no_add_attrs = true;
>> + }
>> + return NULL_TREE;
>> +}
>> +
>> +static const struct attribute_spec loongarch_attribute_table[] =
>> +{
>> + /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
>> + affects_type_identity, handler, exclude } */
>> + { "movable", 0, 0, true, false, false, false,
>> + loongarch_handle_movable_attribute, NULL },
>> + /* The last attribute spec is set to be NULL. */
>> + {}
>> +};
>> +
>> +bool
>> +loongarch_use_anchors_for_symbol_p (const_rtx symbol)
>> +{
>> + tree decl = SYMBOL_REF_DECL (symbol);
>> +
>> + /* A movable attribute indicates the linker may move the symbol
>> away,
>> + so the use of anchor may cause relocation overflow. */
>> + if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES (decl)))
>> + return false;
>> +
>> + return default_use_anchors_for_symbol_p (symbol);
>> +}
>> +
>> /* Initialize the GCC target structure. */
>> #undef TARGET_ASM_ALIGNED_HI_OP
>> #define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
>> @@ -6256,6 +6313,12 @@ loongarch_starting_frame_offset (void)
>> #undef TARGET_HAVE_SPECULATION_SAFE_VALUE
>> #define TARGET_HAVE_SPECULATION_SAFE_VALUE
>> speculation_safe_value_not_needed
>>
>> +#undef TARGET_ATTRIBUTE_TABLE
>> +#define TARGET_ATTRIBUTE_TABLE loongarch_attribute_table
>> +
>> +#undef TARGET_USE_ANCHORS_FOR_SYMBOL_P
>> +#define TARGET_USE_ANCHORS_FOR_SYMBOL_P
>> loongarch_use_anchors_for_symbol_p
>> +
>> struct gcc_target targetm = TARGET_INITIALIZER;
>>
>> #include "gt-loongarch.h"
>> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
>> index 7fe7f8817cd..322d8c05a04 100644
>> --- a/gcc/doc/extend.texi
>> +++ b/gcc/doc/extend.texi
>> @@ -7314,6 +7314,7 @@ attributes.
>> * Blackfin Variable Attributes::
>> * H8/300 Variable Attributes::
>> * IA-64 Variable Attributes::
>> +* LoongArch Variable Attributes::
>> * M32R/D Variable Attributes::
>> * MeP Variable Attributes::
>> * Microsoft Windows Variable Attributes::
>> @@ -8098,6 +8099,21 @@ defined by shared libraries.
>>
>> @end table
>>
>> +@node LoongArch Variable Attributes
>> +@subsection LoongArch Variable Attributes
>> +
>> +One attribute is currently defined for the LoongArch.
>> +
>> +@table @code
>> +@item movable
>> +@cindex @code{movable} variable attribute, LoongArch
>> +Use this attribute on the LoongArch to mark an object possible to be
>> moved
>> +by the linker, so its address is unlimited by the local data section
>> range
>> +specified by the code model even if the object is defined locally.
>> This
>> +attribute is mostly useful if a @code{section} attribute and/or a
>> linker
>> +script will move the object somewhere unexpected by the code model.
>> +@end table
>> +
>> @node M32R/D Variable Attributes
>> @subsection M32R/D Variable Attributes
>>
>> diff --git a/gcc/testsuite/gcc.target/loongarch/attr-movable.c
>> b/gcc/testsuite/gcc.target/loongarch/attr-movable.c
>> new file mode 100644
>> index 00000000000..85b1dd4c59a
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/loongarch/attr-movable.c
>> @@ -0,0 +1,29 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-mexplicit-relocs -mcmodel=normal -O2" } */
>> +/* { dg-final { scan-assembler-not "%pc" } } */
>> +/* { dg-final { scan-assembler-times "%got_pc_hi20" 3 } } */
>> +
>> +/* movable attribute should mark x and y possibly outside of the
>> local
>> + data range defined by the code model, so GOT should be used
>> instead of
>> + PC-relative. */
>> +
>> +int x __attribute__((movable));
>> +int y __attribute__((movable));
>> +
>> +int
>> +test(void)
>> +{
>> + return x + y;
>> +}
>> +
>> +/* The following will be used for kernel per-cpu storage
>> implemention. */
>> +
>> +register char *per_cpu_base __asm__("r21");
>> +static int counter __attribute__((section(".data..percpu"),
>> movable));
>> +
>> +void
>> +inc_counter(void)
>> +{
>> + int *ptr = (int *)(per_cpu_base + (long)&counter);
>> + (*ptr)++;
>> +}
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
[not found] ` <-2muj1c-68saz6jhkcyw3jo1xp-1mgcvnkbqi2wjp6tue-qsso54-emxgu3-k85590-kpgox7-w67u6h3cai1l-5bi887dsgzsu-g4d7i7-wl316qxrucx4kv4on7-mnna36-iremg8-nwc5ot-9041t2-hu8nsl.1659495047941@email.android.com>
@ 2022-08-03 3:10 ` Xi Ruoyao
2022-08-04 7:47 ` Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-03 3:10 UTC (permalink / raw)
To: chenglulu, Chenghua Xu, gcc-patches
Cc: Jinyang He, Huacai Chen, Youling Tang, Wang Xuerui
On Wed, 2022-08-03 at 10:55 +0800, chenglulu@loongson.cn wrote:
> I think there is no problem with this patch。But I have a question. The
> visibility attribute works, so is it necessary to add the moveable
> attribute?
1. My use of -fPIC and visibility is not in the way ELF visibility has
been designed for. It's hardly to tell if it's an legitimate use or a
misuse.
2. Adding -fPIC can make unwanted side effects, especially: if we add
some optimizations only suitable for -fno-PIC, we'll miss them using -
fPIC. Note that -fPIC does not only mean "produce position independent
code", but "produce position independent code *suitable for ELF dynamic
libraries*". So to other people it will be ridiculous to use -fPIC for
kernel.
3. Huacai said he didn't like using __attribute__((visibility)) like
this (in kernel ML) and I share his feeling.
> I'd like to wait for the kernel team to test the performance data of
> the two implementations before deciding whether to support this
> attribute.
>
> What do you think?
Perhaps, I can't access my dev system now anyway (I've configured the
SSH access but then a sudden power surge happened and I didn't
configured automatically power on :( )
>
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v5] LoongArch: add movable attribute
2022-08-03 2:59 ` WANG Xuerui
@ 2022-08-03 3:15 ` Xi Ruoyao
0 siblings, 0 replies; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-03 3:15 UTC (permalink / raw)
To: WANG Xuerui, Chenghua Xu, gcc-patches, Lulu Cheng
Cc: Jinyang He, Huacai Chen, Youling Tang
On Wed, 2022-08-03 at 10:59 +0800, WANG Xuerui wrote:
> I don't think mindlessly caring for vendor forks is always correct. In
> fact I find the name "movable" too generic, and something like
> "force_got_access" could be better.
The problem is "what will this behave *if* we later add some code model
without GOT". If it's named "movable" we generate a full 4-instruction
absolute (or PC-relative) address loading sequence if GOT is disabled.
If it's named "force_got_access" we report an error and reject the code
if GOT is disabled.
> I don't currently have time to test this, unfortunately, due to day job.
> Might be able to give it a whirl one or two week later though...
Unfortunately, I can't access my dev system via SSH too because while
I'm remote, a sudden power surge happened and I forgot to configure an
automatically power-on.
I'm kind of rushy because I want to make it into 12.2, leaving 12.1 the
only exception cannot build Linux >= 6.0. But maybe it just can't be
backported anyway.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-03 3:10 ` 回复:[PATCH " Xi Ruoyao
@ 2022-08-04 7:47 ` Xi Ruoyao
2022-08-05 1:05 ` Lulu Cheng
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-04 7:47 UTC (permalink / raw)
To: chenglulu, Chenghua Xu, gcc-patches
Cc: Youling Tang, Huacai Chen, Jinyang He, Wang Xuerui
On Wed, 2022-08-03 at 11:10 +0800, Xi Ruoyao via Gcc-patches wrote:
> > I'd like to wait for the kernel team to test the performance data of
> > the two implementations before deciding whether to support this
> > attribute.
> >
> > What do you think?
>
> Perhaps, I can't access my dev system now anyway (I've configured the
> SSH access but then a sudden power surge happened and I didn't
> configured automatically power on :( )
Hi folks,
Can someone perform a bench to see if a four-instruction immediate load
sequence can outperform GOT or vice versa? I cannot access my test
system in at least 1 week, and I may be busy preparing Linux From
Scratch 11.2 release in the remaining of August.
Note: if the four-instruction immediate load sequence outperforms GOT,
we should consider use immediate load instead of GOT for -fno-PIC by
default.
P.S. It seems I have trouble accessing gcc400.fsffrance.org. I have a C
Farm account and I've already put
Host gcc400.fsffrance.org
Port 25465
in ~/.ssh/config, and I can access other C farm machines w/o problem.
But:
$ ssh gcc400.fsffrance.org
xry111@gcc400.fsffrance.org: Permission denied (publickey,keyboard-interactive).
If you know the administrator of the C farm machine, can you tell him to
check the configuration? If I can access it I may use some time to
perform the bench (in userspace of course) myself. Thanks.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-04 7:47 ` Xi Ruoyao
@ 2022-08-05 1:05 ` Lulu Cheng
2022-08-05 1:28 ` Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Lulu Cheng @ 2022-08-05 1:05 UTC (permalink / raw)
To: Xi Ruoyao, gcc-patches
Cc: Chenghua Xu, Youling Tang, Huacai Chen, Jinyang He, Wang Xuerui
I'm working on the implementation of specifing attributes of variables
for other architectures. If the address is obtained through the GOT
table and 4 instructions, there is not much difference in performance.
Is it more reasonable for us to refer to the implementation of the model
attribute under the IA64 architecture? I will compare the performance of
the two soon. Do you know the approximate release date of GCC 12.2? I
also want to fix this before 12.2 is released. Thanks!
在 2022/8/4 下午3:47, Xi Ruoyao 写道:
> On Wed, 2022-08-03 at 11:10 +0800, Xi Ruoyao via Gcc-patches wrote:
>
>>> I'd like to wait for the kernel team to test the performance data of
>>> the two implementations before deciding whether to support this
>>> attribute.
>>>
>>> What do you think?
>> Perhaps, I can't access my dev system now anyway (I've configured the
>> SSH access but then a sudden power surge happened and I didn't
>> configured automatically power on :( )
> Hi folks,
>
> Can someone perform a bench to see if a four-instruction immediate load
> sequence can outperform GOT or vice versa? I cannot access my test
> system in at least 1 week, and I may be busy preparing Linux From
> Scratch 11.2 release in the remaining of August.
>
> Note: if the four-instruction immediate load sequence outperforms GOT,
> we should consider use immediate load instead of GOT for -fno-PIC by
> default.
>
> P.S. It seems I have trouble accessing gcc400.fsffrance.org. I have a C
> Farm account and I've already put
>
> Host gcc400.fsffrance.org
> Port 25465
>
> in ~/.ssh/config, and I can access other C farm machines w/o problem.
> But:
>
> $ ssh gcc400.fsffrance.org
> xry111@gcc400.fsffrance.org: Permission denied (publickey,keyboard-interactive).
>
> If you know the administrator of the C farm machine, can you tell him to
> check the configuration? If I can access it I may use some time to
> perform the bench (in userspace of course) myself. Thanks.
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 1:05 ` Lulu Cheng
@ 2022-08-05 1:28 ` Xi Ruoyao
2022-08-05 2:38 ` Lulu Cheng
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-05 1:28 UTC (permalink / raw)
To: Lulu Cheng, gcc-patches
Cc: Chenghua Xu, Youling Tang, Huacai Chen, Jinyang He, Wang Xuerui
On Fri, 2022-08-05 at 09:05 +0800, Lulu Cheng wrote:
> I'm working on the implementation of specifing attributes of variables for other architectures.
> If the address is obtained through the GOT table and 4 instructions, there is not much difference in performance.
In this case I still prefer a GOT table entry because for 4-instruction
absolute addressing sequence we'll need to implement 4 new relocation
types in the kernel module loader.
> Is it more reasonable for us to refer to the implementation of the model attribute under the IA64 architecture?
Maybe we can use "model(got)", "model(abs)", "model(pcrel)" etc.
> I will compare the performance of the two soon. Do you know the approximate release date of GCC 12.2?
> I also want to fix this before 12.2 is released.
GCC 12.2 rc1 will be frozen on Aug 12th.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 1:28 ` Xi Ruoyao
@ 2022-08-05 2:38 ` Lulu Cheng
2022-08-05 2:51 ` Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Lulu Cheng @ 2022-08-05 2:38 UTC (permalink / raw)
To: Xi Ruoyao, gcc-patches
Cc: Chenghua Xu, Youling Tang, Huacai Chen, Jinyang He, Wang Xuerui
在 2022/8/5 上午9:28, Xi Ruoyao 写道:
> On Fri, 2022-08-05 at 09:05 +0800, Lulu Cheng wrote:
>> I'm working on the implementation of specifing attributes of variables for other architectures.
>> If the address is obtained through the GOT table and 4 instructions, there is not much difference in performance.
> In this case I still prefer a GOT table entry because for 4-instruction
> absolute addressing sequence we'll need to implement 4 new relocation
> types in the kernel module loader.
If it is accessed through the GOT table, dynamic relocation is required
when the module is loaded. And accessing the got table may have a cache
miss.
>> Is it more reasonable for us to refer to the implementation of the model attribute under the IA64 architecture?
> Maybe we can use "model(got)", "model(abs)", "model(pcrel)" etc.
We have a set of instruction implementations that can get a relative pc
64-bit offset:
"pcalau12i %1,%%pc_hi20(%3);"
"addi.d %2,$r0,%%pc_lo12(%3);"
"lu32i.d %2,%%pc64_lo20(%3);"
"lu52i.d %2,%2,%%pc64_hi12(%3);"
"add.d %1,%1,%2;",
This set of instructions can be selected according to the size of the
offset:
"pcalau12i %1,%%pc_hi20(%3);"
"addi.d %2,$r0,%%pc_lo12(%3);"
"lu32i.d %2,%%pc64_lo20(%3);"
"add.d %1,%1,%2;",
for offset within signed 52 bits.
or
"pcalau12i %1,%%pc_hi20(%3);"
"addi.d %2,$r0,%%pc_lo12(%3);"
"lu32i.d %2,%%pc64_lo20(%3);"
"lu52i.d %2,%2,%%pc64_hi12(%3);"
"add.d %1,%1,%2;"
for offset within signed 64 bits.
So my idea is "model(normal)","model (large)" etc.
>> I will compare the performance of the two soon. Do you know the approximate release date of GCC 12.2?
>> I also want to fix this before 12.2 is released.
> GCC 12.2 rc1 will be frozen on Aug 12th.
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 2:38 ` Lulu Cheng
@ 2022-08-05 2:51 ` Xi Ruoyao
2022-08-05 3:34 ` Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-05 2:51 UTC (permalink / raw)
To: Lulu Cheng, gcc-patches
Cc: Chenghua Xu, Youling Tang, Huacai Chen, Jinyang He, Wang Xuerui
On Fri, 2022-08-05 at 10:38 +0800, Lulu Cheng wrote:
> > > I'm working on the implementation of specifing attributes of variables for other architectures.
> > > If the address is obtained through the GOT table and 4 instructions, there is not much difference in performance.
> > In this case I still prefer a GOT table entry because for 4-instruction
> > absolute addressing sequence we'll need to implement 4 new relocation
> > types in the kernel module loader.
> If it is accessed through the GOT table, dynamic relocation is required when the module is loaded.
Dynamic relocation is required when the module is loaded anyway. The
.ko modules are actually relocatable ELF objects (produced by ld -r) and
the module loader has to perform some work of a normal linker.
> And accessing the got table may have a cache miss.
/* snip */
> So my idea is "model(normal)","model (large)" etc.
Then should we have an option to disable GOT globally? Maybe for kernel
we'll just "-mno-got -mcmodel=large" (or "extreme"? The kernel image is
loaded at 0x9000000000000000 and the modules are above
0xffff000000000000 so we need to handle 64-bit offset).
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 2:51 ` Xi Ruoyao
@ 2022-08-05 3:34 ` Xi Ruoyao
2022-08-05 3:45 ` Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-05 3:34 UTC (permalink / raw)
To: Lulu Cheng, gcc-patches
Cc: Jinyang He, Chenghua Xu, Huacai Chen, Youling Tang, Wang Xuerui
On Fri, 2022-08-05 at 10:51 +0800, Xi Ruoyao via Gcc-patches wrote:
> > If it is accessed through the GOT table, dynamic relocation is required when the module is loaded.
>
> Dynamic relocation is required when the module is loaded anyway. The
> .ko modules are actually relocatable ELF objects (produced by ld -r) and
> the module loader has to perform some work of a normal linker.
>
> > And accessing the got table may have a cache miss.
>
> /* snip */
>
> > So my idea is "model(normal)","model (large)" etc.
>
> Then should we have an option to disable GOT globally? Maybe for kernel
> we'll just "-mno-got -mcmodel=large" (or "extreme"? The kernel image is
> loaded at 0x9000000000000000 and the modules are above
> 0xffff000000000000 so we need to handle 64-bit offset).
Or maybe we should just use a PC-relative addressing with 4 instructions
instead of GOT for -fno-PIC? Both way consumes 16 bytes (4 instructions
for PC-relative, 2 instructions and a 64-bit GOT entry for GOT) and PC-
relative may be more cache friendly. But such a major change cannot be
backported for 12.2 IMO.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 3:34 ` Xi Ruoyao
@ 2022-08-05 3:45 ` Xi Ruoyao
2022-08-05 4:01 ` Lulu Cheng
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-05 3:45 UTC (permalink / raw)
To: Lulu Cheng, gcc-patches
Cc: Youling Tang, Chenghua Xu, Huacai Chen, Jinyang He, Wang Xuerui
On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
> Or maybe we should just use a PC-relative addressing with 4 instructions
> instead of GOT for -fno-PIC?
Not possible, Glibc does not support R_LARCH_PCALA* relocations in
ld.so. So we still need a -mno-got (or something) option to disable GOT
for special cases like the kernel.
> Both way consumes 16 bytes (4 instructions
> for PC-relative, 2 instructions and a 64-bit GOT entry for GOT) and PC-
> relative may be more cache friendly. But such a major change cannot be
> backported for 12.2 IMO.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 3:45 ` Xi Ruoyao
@ 2022-08-05 4:01 ` Lulu Cheng
2022-08-05 6:03 ` Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Lulu Cheng @ 2022-08-05 4:01 UTC (permalink / raw)
To: Xi Ruoyao, gcc-patches
Cc: Youling Tang, Chenghua Xu, Huacai Chen, Jinyang He, Wang Xuerui
在 2022/8/5 上午11:45, Xi Ruoyao 写道:
> On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
>
>> Or maybe we should just use a PC-relative addressing with 4 instructions
>> instead of GOT for -fno-PIC?
> Not possible, Glibc does not support R_LARCH_PCALA* relocations in
> ld.so. So we still need a -mno-got (or something) option to disable GOT
> for special cases like the kernel.
>
>> Both way consumes 16 bytes (4 instructions
>> for PC-relative, 2 instructions and a 64-bit GOT entry for GOT) and PC-
>> relative may be more cache friendly. But such a major change cannot be
>> backported for 12.2 IMO.
I'm very sorry, my understanding of the precpu variable is wrong, I just
read the code of the kernel you submitted, this precpu variable not only
has a large offset but also has an uncertain address when compiling, so
no matter whether it is addressed with pcrel Still got addressing needs
dynamic relocation when loading. It seems that accessing through the got
table is a better choice.
The name movable is also very vivid to describe this function in the
kernel, indicating that the address of the variable can be changed at
will. But this name is more difficult to understand in gcc, I have no
opinion on other, can this name be changed?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 4:01 ` Lulu Cheng
@ 2022-08-05 6:03 ` Xi Ruoyao
2022-08-05 7:19 ` Lulu Cheng
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-05 6:03 UTC (permalink / raw)
To: Lulu Cheng, gcc-patches
Cc: Youling Tang, Chenghua Xu, Huacai Chen, Jinyang He, Wang Xuerui
On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote:
>
> 在 2022/8/5 上午11:45, Xi Ruoyao 写道:
>
>
>
>
> > On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
> >
> >
> >
> >
> >
> > > Or maybe we should just use a PC-relative addressing with 4 instructions
> > > instead of GOT for -fno-PIC?
> > Not possible, Glibc does not support R_LARCH_PCALA* relocations in
> > ld.so. So we still need a -mno-got (or something) option to disable GOT
> > for special cases like the kernel.
> >
> >
> >
> >
> >
> > > Both way consumes 16 bytes (4 instructions
> > > for PC-relative, 2 instructions and a 64-bit GOT entry for GOT) and PC-
> > > relative may be more cache friendly. But such a major change cannot be
> > > backported for 12.2 IMO.
>
>
>
>
> I'm very sorry, my understanding of the precpu variable is wrong,
> I just read the code of the kernel you submitted, this precpu variable
> not only has a large offset but also has an uncertain address when compiling,
> so no matter whether it is addressed with pcrel Still got addressing needs
> dynamic relocation when loading. It seems that accessing through the got table
> is a better choice.
>
> The name movable is also very vivid to describe this function in the kernel,
> indicating that the address of the variable can be changed at will.
>
> But this name is more difficult to understand in gcc, I have no opinion on other,
> can this name be changed?
Yes, we don't need to be compatible with old vendor compiler IMO.
"force_got_access" as Xuerui suggested?
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 6:03 ` Xi Ruoyao
@ 2022-08-05 7:19 ` Lulu Cheng
2022-08-05 7:41 ` WANG Xuerui
0 siblings, 1 reply; 29+ messages in thread
From: Lulu Cheng @ 2022-08-05 7:19 UTC (permalink / raw)
To: Xi Ruoyao, gcc-patches
Cc: Youling Tang, Chenghua Xu, Huacai Chen, Jinyang He, Wang Xuerui
在 2022/8/5 下午2:03, Xi Ruoyao 写道:
> On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote:
>> 在 2022/8/5 上午11:45, Xi Ruoyao 写道:
>>
>>
>>
>>
>>> On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
>>>
>>>
>>>
>>>
>>>
>>>> Or maybe we should just use a PC-relative addressing with 4 instructions
>>>> instead of GOT for -fno-PIC?
>>> Not possible, Glibc does not support R_LARCH_PCALA* relocations in
>>> ld.so. So we still need a -mno-got (or something) option to disable GOT
>>> for special cases like the kernel.
>>>
>>>
>>>
>>>
>>>
>>>> Both way consumes 16 bytes (4 instructions
>>>> for PC-relative, 2 instructions and a 64-bit GOT entry for GOT) and PC-
>>>> relative may be more cache friendly. But such a major change cannot be
>>>> backported for 12.2 IMO.
>>
>>
>>
>>
>> I'm very sorry, my understanding of the precpu variable is wrong,
>> I just read the code of the kernel you submitted, this precpu variable
>> not only has a large offset but also has an uncertain address when compiling,
>> so no matter whether it is addressed with pcrel Still got addressing needs
>> dynamic relocation when loading. It seems that accessing through the got table
>> is a better choice.
>>
>> The name movable is also very vivid to describe this function in the kernel,
>> indicating that the address of the variable can be changed at will.
>>
>> But this name is more difficult to understand in gcc, I have no opinion on other,
>> can this name be changed?
> Yes, we don't need to be compatible with old vendor compiler IMO.
>
>
> "force_got_access" as Xuerui suggested?
Compared with these names, I think addr_global is better.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 7:19 ` Lulu Cheng
@ 2022-08-05 7:41 ` WANG Xuerui
2022-08-05 7:58 ` Lulu Cheng
0 siblings, 1 reply; 29+ messages in thread
From: WANG Xuerui @ 2022-08-05 7:41 UTC (permalink / raw)
To: Lulu Cheng, Xi Ruoyao, gcc-patches
Cc: Youling Tang, Chenghua Xu, Huacai Chen, Jinyang He
On 2022/8/5 15:19, Lulu Cheng wrote:
>
>
> 在 2022/8/5 下午2:03, Xi Ruoyao 写道:
>> On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote:
>>> 在 2022/8/5 上午11:45, Xi Ruoyao 写道:
>>>
>>>> On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
>>>>
>>>>> Or maybe we should just use a PC-relative addressing with 4 instructions
>>>>> instead of GOT for -fno-PIC?
>>>> Not possible, Glibc does not support R_LARCH_PCALA* relocations in
>>>> ld.so. So we still need a -mno-got (or something) option to disable GOT
>>>> for special cases like the kernel.
>>>>
>>>>> Both way consumes 16 bytes (4 instructions
>>>>> for PC-relative, 2 instructions and a 64-bit GOT entry for GOT) and PC-
>>>>> relative may be more cache friendly. But such a major change cannot be
>>>>> backported for 12.2 IMO.
>>> I'm very sorry, my understanding of the precpu variable is wrong,
>>> I just read the code of the kernel you submitted, this precpu variable
>>> not only has a large offset but also has an uncertain address when compiling,
>>> so no matter whether it is addressed with pcrel Still got addressing needs
>>> dynamic relocation when loading. It seems that accessing through the got table
>>> is a better choice.
>>>
>>> The name movable is also very vivid to describe this function in the kernel,
>>> indicating that the address of the variable can be changed at will.
>>>
>>> But this name is more difficult to understand in gcc, I have no opinion on other,
>>> can this name be changed?
>> Yes, we don't need to be compatible with old vendor compiler IMO.
>>
>>
>> "force_got_access" as Xuerui suggested?
> Compared with these names, I think addr_global is better.
Actually if "model(...)" can be implemented I'd prefer a descriptive
word/phrase inside model(). Because it may well be the case that more
peculiar ways of accessing some special data will have to be supported
in the future, and all of them are kind of "data models" so we'd be able
to nicely group them with model(...).
Otherwise I actually don't have a particularly strong opinion, aside
from "movable" which IMO should definitely not be taken.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 7:41 ` WANG Xuerui
@ 2022-08-05 7:58 ` Lulu Cheng
2022-08-05 9:53 ` Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Lulu Cheng @ 2022-08-05 7:58 UTC (permalink / raw)
To: WANG Xuerui, Xi Ruoyao, gcc-patches
Cc: Youling Tang, Chenghua Xu, Huacai Chen, Jinyang He
在 2022/8/5 下午3:41, WANG Xuerui 写道:
> On 2022/8/5 15:19, Lulu Cheng wrote:
>>
>>
>> 在 2022/8/5 下午2:03, Xi Ruoyao 写道:
>>> On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote:
>>>> 在 2022/8/5 上午11:45, Xi Ruoyao 写道:
>>>>
>>>>> On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
>>>>>
>>>>>> Or maybe we should just use a PC-relative addressing with 4 instructions
>>>>>> instead of GOT for -fno-PIC?
>>>>> Not possible, Glibc does not support R_LARCH_PCALA* relocations in
>>>>> ld.so. So we still need a -mno-got (or something) option to disable GOT
>>>>> for special cases like the kernel.
>>>>>
>>>>>> Both way consumes 16 bytes (4 instructions
>>>>>> for PC-relative, 2 instructions and a 64-bit GOT entry for GOT) and PC-
>>>>>> relative may be more cache friendly. But such a major change cannot be
>>>>>> backported for 12.2 IMO.
>>>> I'm very sorry, my understanding of the precpu variable is wrong,
>>>> I just read the code of the kernel you submitted, this precpu variable
>>>> not only has a large offset but also has an uncertain address when compiling,
>>>> so no matter whether it is addressed with pcrel Still got addressing needs
>>>> dynamic relocation when loading. It seems that accessing through the got table
>>>> is a better choice.
>>>>
>>>> The name movable is also very vivid to describe this function in the kernel,
>>>> indicating that the address of the variable can be changed at will.
>>>>
>>>> But this name is more difficult to understand in gcc, I have no opinion on other,
>>>> can this name be changed?
>>> Yes, we don't need to be compatible with old vendor compiler IMO.
>>>
>>>
>>> "force_got_access" as Xuerui suggested?
>> Compared with these names, I think addr_global is better.
>
> Actually if "model(...)" can be implemented I'd prefer a descriptive
> word/phrase inside model(). Because it may well be the case that more
> peculiar ways of accessing some special data will have to be supported
> in the future, and all of them are kind of "data models" so we'd be
> able to nicely group them with model(...).
>
> Otherwise I actually don't have a particularly strong opinion, aside
> from "movable" which IMO should definitely not be taken.
>
>
I think the model of precpu is not very easy to describe.
model(got)?model(global)? I also want to use attribute model and
-mcmodel together, but this is just an initial idea, what do you think?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 7:58 ` Lulu Cheng
@ 2022-08-05 9:53 ` Xi Ruoyao
2022-08-08 4:53 ` Lulu Cheng
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-05 9:53 UTC (permalink / raw)
To: Lulu Cheng, WANG Xuerui, gcc-patches
Cc: Youling Tang, Chenghua Xu, Huacai Chen, Jinyang He
On Fri, 2022-08-05 at 15:58 +0800, Lulu Cheng wrote:
> I think the model of precpu is not very easy to describe. model(got)?model(global)?
> I also want to use attribute model and -mcmodel together, but this is just an initial idea,
> what do you think?
It seems I had some misunderstanding about IA-64 model attribute. IA-64
actually does not have -mcmodel= options. And a code model only
specifies where "the GOT and the local symbols" are, but our new
attribute should apply for both local symbols and global symbols. So I
don't think we should strongly bind the new attribute and -mcmodel.
Maybe, __attribute__((addressing_model(got/pcrel32/pcrel64/abs32/abs64))
? I think they are explicit enough (we can implement got and pc32
first, and adding the others when we implement other code models).
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-05 9:53 ` Xi Ruoyao
@ 2022-08-08 4:53 ` Lulu Cheng
2022-08-09 11:30 ` Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Lulu Cheng @ 2022-08-08 4:53 UTC (permalink / raw)
To: Xi Ruoyao, gcc-patches
Cc: WANG Xuerui, Youling Tang, Chenghua Xu, Huacai Chen, Jinyang He
在 2022/8/5 下午5:53, Xi Ruoyao 写道:
> On Fri, 2022-08-05 at 15:58 +0800, Lulu Cheng wrote:
>> I think the model of precpu is not very easy to describe. model(got)?model(global)?
>> I also want to use attribute model and -mcmodel together, but this is just an initial idea,
>> what do you think?
> It seems I had some misunderstanding about IA-64 model attribute. IA-64
> actually does not have -mcmodel= options. And a code model only
> specifies where "the GOT and the local symbols" are, but our new
> attribute should apply for both local symbols and global symbols. So I
> don't think we should strongly bind the new attribute and -mcmodel.
>
> Maybe, __attribute__((addressing_model(got/pcrel32/pcrel64/abs32/abs64))
> ? I think they are explicit enough (we can implement got and pc32
> first, and adding the others when we implement other code models).
I still think it makes a little bit more sense to put attribute(model)
and -mcmodel together.
-mcmodel sets the access range of all symbols in a single file, and
attribute (model) sets the
accsess range of a single symbol in a file. For example
__attribute__((model(normal/large/extreme))).
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-08 4:53 ` Lulu Cheng
@ 2022-08-09 11:30 ` Xi Ruoyao
2022-08-09 13:03 ` Lulu Cheng
0 siblings, 1 reply; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-09 11:30 UTC (permalink / raw)
To: Lulu Cheng, gcc-patches
Cc: WANG Xuerui, Youling Tang, Chenghua Xu, Huacai Chen, Jinyang He
Sorry for late reply, I'm rebuilding my entire Linux system (from
scratch) for Glibc-2.36 and Binutils-2.39 update and I just reached the
mail client.
On Mon, 2022-08-08 at 12:53 +0800, Lulu Cheng wrote:
> I still think it makes a little bit more sense to put attribute(model)
> and -mcmodel together.
>
> -mcmodel sets the access range of all symbols in a single fileand
> attribute (model) sets the
>
> accsess range of a single symbol in a file. For example
> __attribute__((model(normal/large/extreme))).
It might make sense, but then it would not be what we want for per-CPU
symbols. What we want here is "treat a local symbol as-if it's global",
while each code model may already treat local symbol and global symbol
differently.
Disambiguation: here "local" means "defined in this TU", "global"
otherwise (not "local variable" in C).
I'll send v6 with the name "addr_global" if no objection.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-09 11:30 ` Xi Ruoyao
@ 2022-08-09 13:03 ` Lulu Cheng
2022-08-09 14:04 ` Xi Ruoyao
0 siblings, 1 reply; 29+ messages in thread
From: Lulu Cheng @ 2022-08-09 13:03 UTC (permalink / raw)
To: Xi Ruoyao, gcc-patches
Cc: WANG Xuerui, Youling Tang, Chenghua Xu, Huacai Chen, Jinyang He
在 2022/8/9 下午7:30, Xi Ruoyao 写道:
> Sorry for late reply, I'm rebuilding my entire Linux system (from
> scratch) for Glibc-2.36 and Binutils-2.39 update and I just reached the
> mail client.
>
> On Mon, 2022-08-08 at 12:53 +0800, Lulu Cheng wrote:
>> I still think it makes a little bit more sense to put attribute(model)
>> and -mcmodel together.
>>
>> -mcmodel sets the access range of all symbols in a single fileand
>> attribute (model) sets the
>>
>> accsess range of a single symbol in a file. For example
>> __attribute__((model(normal/large/extreme))).
> It might make sense, but then it would not be what we want for per-CPU
> symbols. What we want here is "treat a local symbol as-if it's global",
> while each code model may already treat local symbol and global symbol
> differently.
>
> Disambiguation: here "local" means "defined in this TU", "global"
> otherwise (not "local variable" in C).
>
> I'll send v6 with the name "addr_global" if no objection.
>
I am implementing the mode of cmodel=extreme. In this mode, the value of
the relative offset is a signed 64-bit value, so this can solve the
access problem of the variables of the kernel precpu.
So I wonder if it is necessary to add another attribute like addr_global?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 回复:[PATCH v5] LoongArch: add movable attribute
2022-08-09 13:03 ` Lulu Cheng
@ 2022-08-09 14:04 ` Xi Ruoyao
0 siblings, 0 replies; 29+ messages in thread
From: Xi Ruoyao @ 2022-08-09 14:04 UTC (permalink / raw)
To: Lulu Cheng, gcc-patches
Cc: WANG Xuerui, Youling Tang, Chenghua Xu, Huacai Chen, Jinyang He
On Tue, 2022-08-09 at 21:03 +0800, Lulu Cheng wrote:
>
> 在 2022/8/9 下午7:30, Xi Ruoyao 写道:
>
>
>
>
> > Sorry for late reply, I'm rebuilding my entire Linux system (from
> > scratch) for Glibc-2.36 and Binutils-2.39 update and I just reached the
> > mail client.
> >
> > On Mon, 2022-08-08 at 12:53 +0800, Lulu Cheng wrote:
> >
> >
> >
> >
> > > I still think it makes a little bit more sense to put attribute(model)
> > > and -mcmodel together.
> > >
> > > -mcmodel sets the access range of all symbols in a single fileand
> > > attribute (model) sets the
> > >
> > > accsess range of a single symbol in a file. For example
> > > __attribute__((model(normal/large/extreme))).
> > It might make sense, but then it would not be what we want for per-CPU
> > symbols. What we want here is "treat a local symbol as-if it's global",
> > while each code model may already treat local symbol and global symbol
> > differently.
> >
> > Disambiguation: here "local" means "defined in this TU", "global"
> > otherwise (not "local variable" in C).
> >
> > I'll send v6 with the name "addr_global" if no objection.
> >
> I am implementing the mode of cmodel=extreme.
> In this mode, the value of the relative offset is a signed 64-bit value,
> so this can solve the access problem of the variables of the kernel precpu.
> So I wonder if it is necessary to add another attribute like addr_global?
If we use GOT I can implement only PC_HI20 and PC_LO12 relocs in kernel
module loader. If we use extreme I'll need to implement 4 ABS
relocations along with them.
But "the less the better" is not a very strong reason anyway.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2022-08-09 14:04 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-29 14:22 [PATCH] LoongArch: add addr_global attribute Xi Ruoyao
2022-07-29 15:31 ` [PATCH v2] " Xi Ruoyao
2022-07-29 17:17 ` [PATCH v3] " Xi Ruoyao
2022-07-30 3:13 ` Lulu Cheng
2022-07-30 6:03 ` Huacai Chen
2022-07-31 9:05 ` Chenghua Xu
2022-08-01 10:04 ` [PATCH v4] LoongArch: add movable attribute Xi Ruoyao
2022-08-01 10:07 ` [PATCH v5] " Xi Ruoyao
2022-08-03 1:36 ` Xi Ruoyao
2022-08-03 2:59 ` WANG Xuerui
2022-08-03 3:15 ` Xi Ruoyao
[not found] ` <-2muj1c-68saz6jhkcyw3jo1xp-1mgcvnkbqi2wjp6tue-qsso54-emxgu3-k85590-kpgox7-w67u6h3cai1l-5bi887dsgzsu-g4d7i7-wl316qxrucx4kv4on7-mnna36-iremg8-nwc5ot-9041t2-hu8nsl.1659495047941@email.android.com>
2022-08-03 3:10 ` 回复:[PATCH " Xi Ruoyao
2022-08-04 7:47 ` Xi Ruoyao
2022-08-05 1:05 ` Lulu Cheng
2022-08-05 1:28 ` Xi Ruoyao
2022-08-05 2:38 ` Lulu Cheng
2022-08-05 2:51 ` Xi Ruoyao
2022-08-05 3:34 ` Xi Ruoyao
2022-08-05 3:45 ` Xi Ruoyao
2022-08-05 4:01 ` Lulu Cheng
2022-08-05 6:03 ` Xi Ruoyao
2022-08-05 7:19 ` Lulu Cheng
2022-08-05 7:41 ` WANG Xuerui
2022-08-05 7:58 ` Lulu Cheng
2022-08-05 9:53 ` Xi Ruoyao
2022-08-08 4:53 ` Lulu Cheng
2022-08-09 11:30 ` Xi Ruoyao
2022-08-09 13:03 ` Lulu Cheng
2022-08-09 14:04 ` Xi Ruoyao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).