__attribute__((retain)) && llvm.used/llvm.compiler.used

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

__attribute__((retain)) && llvm.used/llvm.compiler.used

Manas via cfe-dev
Currently __attribute__((used)) lowers to llvm.used.

* On Mach-O, a GlobalObject in llvm.used gets the S_ATTR_NO_DEAD_STRIP
attribute, which prevents linker GC (dead stripping).
* On COFF, a non-local-linkage GlobalObject[1] in llvm.used gets the
/INCLUDE: linker option (similar to ELF `ld -u`), which prevents
linker GC.
  It should be possible to work with local linkage GlobalObject's as
well but that will require a complex COMDAT dance.
* On ELF, a global object llvm.used can be discarded by
ld.bfd/gold/ld.lld --gc-sections.
  (If the section is a C identifier name, __start_/__stop_ relocations
from a live input section can retain the section, even if its defined
symbols are not referenced. [2] .
  I understand that some folks use `__attribute__((used,
section("C_ident")))` and expect the sections to be similar to GC
roots, however,
  non-C-identifier cases are very common, too. They don't get
__start_/__stop_ linker magic and the sections can always be GCed.
  )

In LangRef, the description of llvm.used contains:

> If a symbol appears in the @llvm.used list, then the compiler, assembler, and **linker** are required to treat the symbol as if there is a reference to the symbol that it cannot see (which is why they have to be named). For example, if a variable has internal linkage and no references other than that from the @llvm.used list, it cannot be deleted. This is commonly used to represent references from inline asms and other things the compiler cannot “see”, and corresponds to “attribute((used))” in GNU C.

Note that the "linker" part does not match the reality on ELF targets.
It does match the reality on Mach-O and partially on COFF.

llvm.compiler.used:

> The @llvm.compiler.used directive is the same as the @llvm.used directive, except that it only prevents the compiler from touching the symbol. On targets that support it, this allows an **intelligent linker to optimize references to the symbol without being impeded** as it would be by @llvm.used.

Note that this explicitly mentions linker GC, so this appears to be
the closest thing to __attribute__((used)) on ELF.
However, LangRef also says:

> This is a rare construct that should only be used in rare circumstances, and should not be exposed to source languages.



My goal is to implement __attribute__((retain)) (which will be in GCC
11) on ELF. GCC folks think that 'used' and 'retain are orthogonal.
(see https://reviews.llvm.org/D96838#2578127)

Shall we

1. Lift the source language restriction on llvm.compiler.used and
change __attribute__((used)) to use llvm.compiler.used on ELF.
2. Or add a metadata (like https://reviews.llvm.org/D96837)?


I lean to option 1 to leverage the existing mechanism.
The downside is that clang codegen will have some target inconsistency
(llvm.compiler.used on ELF while llvm.used on others).



[1]: The implementation additionally allows GlobalAlias.
[2]: See https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order
"C identifier name sections" for details.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: __attribute__((retain)) && llvm.used/llvm.compiler.used

Manas via cfe-dev
On 2021-02-24, Fāng-ruì Sòng wrote:

>Currently __attribute__((used)) lowers to llvm.used.
>
>* On Mach-O, a GlobalObject in llvm.used gets the S_ATTR_NO_DEAD_STRIP
>attribute, which prevents linker GC (dead stripping).
>* On COFF, a non-local-linkage GlobalObject[1] in llvm.used gets the
>/INCLUDE: linker option (similar to ELF `ld -u`), which prevents
>linker GC.
>  It should be possible to work with local linkage GlobalObject's as
>well but that will require a complex COMDAT dance.
>* On ELF, a global object llvm.used can be discarded by
>ld.bfd/gold/ld.lld --gc-sections.
>  (If the section is a C identifier name, __start_/__stop_ relocations
>from a live input section can retain the section, even if its defined
>symbols are not referenced. [2] .
>  I understand that some folks use `__attribute__((used,
>section("C_ident")))` and expect the sections to be similar to GC
>roots, however,
>  non-C-identifier cases are very common, too. They don't get
>__start_/__stop_ linker magic and the sections can always be GCed.
>  )
>
>In LangRef, the description of llvm.used contains:
>
>> If a symbol appears in the @llvm.used list, then the compiler, assembler, and **linker** are required to treat the symbol as if there is a reference to the symbol that it cannot see (which is why they have to be named). For example, if a variable has internal linkage and no references other than that from the @llvm.used list, it cannot be deleted. This is commonly used to represent references from inline asms and other things the compiler cannot “see”, and corresponds to “attribute((used))” in GNU C.
>
>Note that the "linker" part does not match the reality on ELF targets.
>It does match the reality on Mach-O and partially on COFF.
>
>llvm.compiler.used:
>
>> The @llvm.compiler.used directive is the same as the @llvm.used directive, except that it only prevents the compiler from touching the symbol. On targets that support it, this allows an **intelligent linker to optimize references to the symbol without being impeded** as it would be by @llvm.used.
>
>Note that this explicitly mentions linker GC, so this appears to be
>the closest thing to __attribute__((used)) on ELF.
>However, LangRef also says:
>
>> This is a rare construct that should only be used in rare circumstances, and should not be exposed to source languages.
>
>
>
>My goal is to implement __attribute__((retain)) (which will be in GCC
>11) on ELF. GCC folks think that 'used' and 'retain are orthogonal.
>(see https://reviews.llvm.org/D96838#2578127)
>
>Shall we
>
>1. Lift the source language restriction on llvm.compiler.used and
>change __attribute__((used)) to use llvm.compiler.used on ELF.

It is too late here and I did not think of it clearly;-)

Clarify:

1. Lift the source language restriction on llvm.compiler.used, let llvm.used use SHF_GNU_RETAIN on ELF, and change __attribute__((used)) to use llvm.compiler.used on ELF.


__attribute__((retain)) has semantics which are not described by
llvm.used/llvm.compiler.used.  To facilitate linker GC, __attribute__((retain))
causes the section to be placed in a unique section. The separate section
behavior can be undesired in some cases (e.g. poorly written Linux kernel linker
scripts which expect one section per name).

So in the -fno-function-sections -fno-data-sections case, a retained
function/variable does not cause the whole .text/.data/.rodata to be retained.

The test llvm/test/CodeGen/X86/elf-retain.ll in https://reviews.llvm.org/D96837
demonstrates the behavior.  So I am not particularly clear that we should use
llvm.compiler.used/llvm.used to describe __attribute__((retain)) .

>2. Or add a metadata (like https://reviews.llvm.org/D96837)?
>
>
>I lean to option 1 to leverage the existing mechanism.
>The downside is that clang codegen will have some target inconsistency
>(llvm.compiler.used on ELF while llvm.used on others).
>
>
>
>[1]: The implementation additionally allows GlobalAlias.
>[2]: See https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order
>"C identifier name sections" for details.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: __attribute__((retain)) && llvm.used/llvm.compiler.used

Manas via cfe-dev
(best to include folks from previous conversations in threads - sometimes we can't all keep up to date with all the threads happening - so I've added John McCall here, and echristo since he might have some thoughts on this too)

I'd lean towards (1) too myself - give the LLVM constructs consistent semantics, and deal with the platform differences in the frontend during the mapping down to LLVM.

On Wed, Feb 24, 2021 at 1:09 AM Fāng-ruì Sòng via cfe-dev <[hidden email]> wrote:
On 2021-02-24, Fāng-ruì Sòng wrote:
>Currently __attribute__((used)) lowers to llvm.used.
>
>* On Mach-O, a GlobalObject in llvm.used gets the S_ATTR_NO_DEAD_STRIP
>attribute, which prevents linker GC (dead stripping).
>* On COFF, a non-local-linkage GlobalObject[1] in llvm.used gets the
>/INCLUDE: linker option (similar to ELF `ld -u`), which prevents
>linker GC.
>  It should be possible to work with local linkage GlobalObject's as
>well but that will require a complex COMDAT dance.
>* On ELF, a global object llvm.used can be discarded by
>ld.bfd/gold/ld.lld --gc-sections.
>  (If the section is a C identifier name, __start_/__stop_ relocations
>from a live input section can retain the section, even if its defined
>symbols are not referenced. [2] .
>  I understand that some folks use `__attribute__((used,
>section("C_ident")))` and expect the sections to be similar to GC
>roots, however,
>  non-C-identifier cases are very common, too. They don't get
>__start_/__stop_ linker magic and the sections can always be GCed.
>  )
>
>In LangRef, the description of llvm.used contains:
>
>> If a symbol appears in the @llvm.used list, then the compiler, assembler, and **linker** are required to treat the symbol as if there is a reference to the symbol that it cannot see (which is why they have to be named). For example, if a variable has internal linkage and no references other than that from the @llvm.used list, it cannot be deleted. This is commonly used to represent references from inline asms and other things the compiler cannot “see”, and corresponds to “attribute((used))” in GNU C.
>
>Note that the "linker" part does not match the reality on ELF targets.
>It does match the reality on Mach-O and partially on COFF.
>
>llvm.compiler.used:
>
>> The @llvm.compiler.used directive is the same as the @llvm.used directive, except that it only prevents the compiler from touching the symbol. On targets that support it, this allows an **intelligent linker to optimize references to the symbol without being impeded** as it would be by @llvm.used.
>
>Note that this explicitly mentions linker GC, so this appears to be
>the closest thing to __attribute__((used)) on ELF.
>However, LangRef also says:
>
>> This is a rare construct that should only be used in rare circumstances, and should not be exposed to source languages.
>
>
>
>My goal is to implement __attribute__((retain)) (which will be in GCC
>11) on ELF. GCC folks think that 'used' and 'retain are orthogonal.
>(see https://reviews.llvm.org/D96838#2578127)
>
>Shall we
>
>1. Lift the source language restriction on llvm.compiler.used and
>change __attribute__((used)) to use llvm.compiler.used on ELF.

It is too late here and I did not think of it clearly;-)

Clarify:

1. Lift the source language restriction on llvm.compiler.used, let llvm.used use SHF_GNU_RETAIN on ELF, and change __attribute__((used)) to use llvm.compiler.used on ELF.


__attribute__((retain)) has semantics which are not described by
llvm.used/llvm.compiler.used.  To facilitate linker GC, __attribute__((retain))
causes the section to be placed in a unique section. The separate section
behavior can be undesired in some cases (e.g. poorly written Linux kernel linker
scripts which expect one section per name).

So in the -fno-function-sections -fno-data-sections case, a retained
function/variable does not cause the whole .text/.data/.rodata to be retained.

The test llvm/test/CodeGen/X86/elf-retain.ll in https://reviews.llvm.org/D96837
demonstrates the behavior.  So I am not particularly clear that we should use
llvm.compiler.used/llvm.used to describe __attribute__((retain)) .

>2. Or add a metadata (like https://reviews.llvm.org/D96837)?
>
>
>I lean to option 1 to leverage the existing mechanism.
>The downside is that clang codegen will have some target inconsistency
>(llvm.compiler.used on ELF while llvm.used on others).
>
>
>
>[1]: The implementation additionally allows GlobalAlias.
>[2]: See https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order
>"C identifier name sections" for details.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: __attribute__((retain)) && llvm.used/llvm.compiler.used

Manas via cfe-dev
On Wed, Feb 24, 2021 at 10:40 AM David Blaikie <[hidden email]> wrote:
>
> (best to include folks from previous conversations in threads - sometimes we can't all keep up to date with all the threads happening - so I've added John McCall here, and echristo since he might have some thoughts on this too)
>
> I'd lean towards (1) too myself - give the LLVM constructs consistent semantics, and deal with the platform differences in the frontend during the mapping down to LLVM.

I chatted with Saleem Abdulrasool, who is in favor of (1), too.

I am going to send these patches:

(a) Add CodeGenModule::addUsedOrCompilerUsedGlobal (which uses
llvm.compiler.used for ELF and llvm.used for the others). Migrate some
addUsedGlobal call sites to use addUsedOrCompilerUsedGlobal.
(b) Add __attribute__((retain))
(c) Change llvm.used to use SHF_GNU_RETAIN if integrated assembler or
binutils>=2.36

Currently llvm.used/llvm.compiler.used should have no difference on
ELF, so (a) & (b) do not affect users who don't use 'retain'.

(c) will change the binary format representation of llvm.used, so
there is some risk if the consumer is not prepared for multiple
sections of the same name (which means they already break with
-fno-unique-section-names, but the option is rare).
On very large C/C++ projects, llvm.used has usually 0 or 1 element.
ObjC can have multiple llvm.used but that should work. So if there is
risk, the risk for other frontends.
I don't see a way to avoid that, but they can switch to llvm.compiler.used.

Non-ELF users should not observe anything different.

> On Wed, Feb 24, 2021 at 1:09 AM Fāng-ruì Sòng via cfe-dev <[hidden email]> wrote:
>>
>> On 2021-02-24, Fāng-ruì Sòng wrote:
>> >Currently __attribute__((used)) lowers to llvm.used.
>> >
>> >* On Mach-O, a GlobalObject in llvm.used gets the S_ATTR_NO_DEAD_STRIP
>> >attribute, which prevents linker GC (dead stripping).
>> >* On COFF, a non-local-linkage GlobalObject[1] in llvm.used gets the
>> >/INCLUDE: linker option (similar to ELF `ld -u`), which prevents
>> >linker GC.
>> >  It should be possible to work with local linkage GlobalObject's as
>> >well but that will require a complex COMDAT dance.
>> >* On ELF, a global object llvm.used can be discarded by
>> >ld.bfd/gold/ld.lld --gc-sections.
>> >  (If the section is a C identifier name, __start_/__stop_ relocations
>> >from a live input section can retain the section, even if its defined
>> >symbols are not referenced. [2] .
>> >  I understand that some folks use `__attribute__((used,
>> >section("C_ident")))` and expect the sections to be similar to GC
>> >roots, however,
>> >  non-C-identifier cases are very common, too. They don't get
>> >__start_/__stop_ linker magic and the sections can always be GCed.
>> >  )
>> >
>> >In LangRef, the description of llvm.used contains:
>> >
>> >> If a symbol appears in the @llvm.used list, then the compiler, assembler, and **linker** are required to treat the symbol as if there is a reference to the symbol that it cannot see (which is why they have to be named). For example, if a variable has internal linkage and no references other than that from the @llvm.used list, it cannot be deleted. This is commonly used to represent references from inline asms and other things the compiler cannot “see”, and corresponds to “attribute((used))” in GNU C.
>> >
>> >Note that the "linker" part does not match the reality on ELF targets.
>> >It does match the reality on Mach-O and partially on COFF.
>> >
>> >llvm.compiler.used:
>> >
>> >> The @llvm.compiler.used directive is the same as the @llvm.used directive, except that it only prevents the compiler from touching the symbol. On targets that support it, this allows an **intelligent linker to optimize references to the symbol without being impeded** as it would be by @llvm.used.
>> >
>> >Note that this explicitly mentions linker GC, so this appears to be
>> >the closest thing to __attribute__((used)) on ELF.
>> >However, LangRef also says:
>> >
>> >> This is a rare construct that should only be used in rare circumstances, and should not be exposed to source languages.
>> >
>> >
>> >
>> >My goal is to implement __attribute__((retain)) (which will be in GCC
>> >11) on ELF. GCC folks think that 'used' and 'retain are orthogonal.
>> >(see https://reviews.llvm.org/D96838#2578127)
>> >
>> >Shall we
>> >
>> >1. Lift the source language restriction on llvm.compiler.used and
>> >change __attribute__((used)) to use llvm.compiler.used on ELF.
>>
>> It is too late here and I did not think of it clearly;-)
>>
>> Clarify:
>>
>> 1. Lift the source language restriction on llvm.compiler.used, let llvm.used use SHF_GNU_RETAIN on ELF, and change __attribute__((used)) to use llvm.compiler.used on ELF.
>>
>>
>> __attribute__((retain)) has semantics which are not described by
>> llvm.used/llvm.compiler.used.  To facilitate linker GC, __attribute__((retain))
>> causes the section to be placed in a unique section. The separate section
>> behavior can be undesired in some cases (e.g. poorly written Linux kernel linker
>> scripts which expect one section per name).
>>
>> So in the -fno-function-sections -fno-data-sections case, a retained
>> function/variable does not cause the whole .text/.data/.rodata to be retained.
>>
>> The test llvm/test/CodeGen/X86/elf-retain.ll in https://reviews.llvm.org/D96837
>> demonstrates the behavior.  So I am not particularly clear that we should use
>> llvm.compiler.used/llvm.used to describe __attribute__((retain)) .
>>
>> >2. Or add a metadata (like https://reviews.llvm.org/D96837)?
>> >
>> >
>> >I lean to option 1 to leverage the existing mechanism.
>> >The downside is that clang codegen will have some target inconsistency
>> >(llvm.compiler.used on ELF while llvm.used on others).
>> >
>> >
>> >
>> >[1]: The implementation additionally allows GlobalAlias.
>> >[2]: See https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order
>> >"C identifier name sections" for details.
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



--
宋方睿
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: __attribute__((retain)) && llvm.used/llvm.compiler.used

Manas via cfe-dev
> (c) Change llvm.used to use SHF_GNU_RETAIN if integrated assembler or
> binutils>=2.36

I am curious how you intend to check if binutils>=2.36.  This is not
something you can decide when the compiler is built.
--paulr


> -----Original Message-----
> From: cfe-dev <[hidden email]> On Behalf Of Fang-ruì Sòng
> via cfe-dev
> Sent: Wednesday, February 24, 2021 2:03 PM
> To: David Blaikie <[hidden email]>
> Cc: LLVM Developers Mailing List <[hidden email]>; cfe-dev <cfe-
> [hidden email]>
> Subject: Re: [cfe-dev] __attribute__((retain)) &&
> llvm.used/llvm.compiler.used
>
> On Wed, Feb 24, 2021 at 10:40 AM David Blaikie <[hidden email]> wrote:
> >
> > (best to include folks from previous conversations in threads -
> sometimes we can't all keep up to date with all the threads happening - so
> I've added John McCall here, and echristo since he might have some
> thoughts on this too)
> >
> > I'd lean towards (1) too myself - give the LLVM constructs consistent
> semantics, and deal with the platform differences in the frontend during
> the mapping down to LLVM.
>
> I chatted with Saleem Abdulrasool, who is in favor of (1), too.
>
> I am going to send these patches:
>
> (a) Add CodeGenModule::addUsedOrCompilerUsedGlobal (which uses
> llvm.compiler.used for ELF and llvm.used for the others). Migrate some
> addUsedGlobal call sites to use addUsedOrCompilerUsedGlobal.
> (b) Add __attribute__((retain))
> (c) Change llvm.used to use SHF_GNU_RETAIN if integrated assembler or
> binutils>=2.36
>
> Currently llvm.used/llvm.compiler.used should have no difference on
> ELF, so (a) & (b) do not affect users who don't use 'retain'.
>
> (c) will change the binary format representation of llvm.used, so
> there is some risk if the consumer is not prepared for multiple
> sections of the same name (which means they already break with
> -fno-unique-section-names, but the option is rare).
> On very large C/C++ projects, llvm.used has usually 0 or 1 element.
> ObjC can have multiple llvm.used but that should work. So if there is
> risk, the risk for other frontends.
> I don't see a way to avoid that, but they can switch to
> llvm.compiler.used.
>
> Non-ELF users should not observe anything different.
>
> > On Wed, Feb 24, 2021 at 1:09 AM Fāng-ruì Sòng via cfe-dev <cfe-
> [hidden email]> wrote:
> >>
> >> On 2021-02-24, Fāng-ruì Sòng wrote:
> >> >Currently __attribute__((used)) lowers to llvm.used.
> >> >
> >> >* On Mach-O, a GlobalObject in llvm.used gets the S_ATTR_NO_DEAD_STRIP
> >> >attribute, which prevents linker GC (dead stripping).
> >> >* On COFF, a non-local-linkage GlobalObject[1] in llvm.used gets the
> >> >/INCLUDE: linker option (similar to ELF `ld -u`), which prevents
> >> >linker GC.
> >> >  It should be possible to work with local linkage GlobalObject's as
> >> >well but that will require a complex COMDAT dance.
> >> >* On ELF, a global object llvm.used can be discarded by
> >> >ld.bfd/gold/ld.lld --gc-sections.
> >> >  (If the section is a C identifier name, __start_/__stop_ relocations
> >> >from a live input section can retain the section, even if its defined
> >> >symbols are not referenced. [2] .
> >> >  I understand that some folks use `__attribute__((used,
> >> >section("C_ident")))` and expect the sections to be similar to GC
> >> >roots, however,
> >> >  non-C-identifier cases are very common, too. They don't get
> >> >__start_/__stop_ linker magic and the sections can always be GCed.
> >> >  )
> >> >
> >> >In LangRef, the description of llvm.used contains:
> >> >
> >> >> If a symbol appears in the @llvm.used list, then the compiler,
> assembler, and **linker** are required to treat the symbol as if there is
> a reference to the symbol that it cannot see (which is why they have to be
> named). For example, if a variable has internal linkage and no references
> other than that from the @llvm.used list, it cannot be deleted. This is
> commonly used to represent references from inline asms and other things
> the compiler cannot “see”, and corresponds to “attribute((used))” in GNU
> C.
> >> >
> >> >Note that the "linker" part does not match the reality on ELF targets.
> >> >It does match the reality on Mach-O and partially on COFF.
> >> >
> >> >llvm.compiler.used:
> >> >
> >> >> The @llvm.compiler.used directive is the same as the @llvm.used
> directive, except that it only prevents the compiler from touching the
> symbol. On targets that support it, this allows an **intelligent linker to
> optimize references to the symbol without being impeded** as it would be
> by @llvm.used.
> >> >
> >> >Note that this explicitly mentions linker GC, so this appears to be
> >> >the closest thing to __attribute__((used)) on ELF.
> >> >However, LangRef also says:
> >> >
> >> >> This is a rare construct that should only be used in rare
> circumstances, and should not be exposed to source languages.
> >> >
> >> >
> >> >
> >> >My goal is to implement __attribute__((retain)) (which will be in GCC
> >> >11) on ELF. GCC folks think that 'used' and 'retain are orthogonal.
> >> >(see
> https://urldefense.com/v3/__https://reviews.llvm.org/D96838*2578127__;Iw!!
> JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz-sSt4Y-
> y3hXRPvXMA$ )
> >> >
> >> >Shall we
> >> >
> >> >1. Lift the source language restriction on llvm.compiler.used and
> >> >change __attribute__((used)) to use llvm.compiler.used on ELF.
> >>
> >> It is too late here and I did not think of it clearly;-)
> >>
> >> Clarify:
> >>
> >> 1. Lift the source language restriction on llvm.compiler.used, let
> llvm.used use SHF_GNU_RETAIN on ELF, and change __attribute__((used)) to
> use llvm.compiler.used on ELF.
> >>
> >>
> >> __attribute__((retain)) has semantics which are not described by
> >> llvm.used/llvm.compiler.used.  To facilitate linker GC,
> __attribute__((retain))
> >> causes the section to be placed in a unique section. The separate
> section
> >> behavior can be undesired in some cases (e.g. poorly written Linux
> kernel linker
> >> scripts which expect one section per name).
> >>
> >> So in the -fno-function-sections -fno-data-sections case, a retained
> >> function/variable does not cause the whole .text/.data/.rodata to be
> retained.
> >>
> >> The test llvm/test/CodeGen/X86/elf-retain.ll in
> https://urldefense.com/v3/__https://reviews.llvm.org/D96837__;!!JmoZiZGBv3
> RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz-sSt4Y-y3igRCpu4Q$
> >> demonstrates the behavior.  So I am not particularly clear that we
> should use
> >> llvm.compiler.used/llvm.used to describe __attribute__((retain)) .
> >>
> >> >2. Or add a metadata (like
> https://urldefense.com/v3/__https://reviews.llvm.org/D96837)?__;!!JmoZiZGB
> v3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz-sSt4Y-
> y3j8yTbbsA$
> >> >
> >> >
> >> >I lean to option 1 to leverage the existing mechanism.
> >> >The downside is that clang codegen will have some target inconsistency
> >> >(llvm.compiler.used on ELF while llvm.used on others).
> >> >
> >> >
> >> >
> >> >[1]: The implementation additionally allows GlobalAlias.
> >> >[2]: See https://urldefense.com/v3/__https://maskray.me/blog/2021-01-
> 31-metadata-sections-comdat-and-shf-link-
> order__;!!JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9
> Gz-sSt4Y-y3jIbWqo9A$
> >> >"C identifier name sections" for details.
> >> _______________________________________________
> >> cfe-dev mailing list
> >> [hidden email]
> >> https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/cfe-
> dev__;!!JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz
> -sSt4Y-y3gvE5g2Qg$
>
>
>
> --
> 宋方睿
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/cfe-
> dev__;!!JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz
> -sSt4Y-y3gvE5g2Qg$
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: __attribute__((retain)) && llvm.used/llvm.compiler.used

Manas via cfe-dev
On Wed, Feb 24, 2021 at 11:50 AM <[hidden email]> wrote:
>
> > (c) Change llvm.used to use SHF_GNU_RETAIN if integrated assembler or
> > binutils>=2.36
>
> I am curious how you intend to check if binutils>=2.36.  This is not
> something you can decide when the compiler is built.
> --paulr

-fintegrated-as can use SHF_GNU_RETAIN. GNU ld not recognizing
SHF_GNU_RETAIN just ignores the flag (ELF spirit: ignore what you
don't understand).
-fno-integrated-as users (rare) can use -fbinutils-version=2.36
(https://reviews.llvm.org/D85474 )

>
> > -----Original Message-----
> > From: cfe-dev <[hidden email]> On Behalf Of Fang-ruì Sòng
> > via cfe-dev
> > Sent: Wednesday, February 24, 2021 2:03 PM
> > To: David Blaikie <[hidden email]>
> > Cc: LLVM Developers Mailing List <[hidden email]>; cfe-dev <cfe-
> > [hidden email]>
> > Subject: Re: [cfe-dev] __attribute__((retain)) &&
> > llvm.used/llvm.compiler.used
> >
> > On Wed, Feb 24, 2021 at 10:40 AM David Blaikie <[hidden email]> wrote:
> > >
> > > (best to include folks from previous conversations in threads -
> > sometimes we can't all keep up to date with all the threads happening - so
> > I've added John McCall here, and echristo since he might have some
> > thoughts on this too)
> > >
> > > I'd lean towards (1) too myself - give the LLVM constructs consistent
> > semantics, and deal with the platform differences in the frontend during
> > the mapping down to LLVM.
> >
> > I chatted with Saleem Abdulrasool, who is in favor of (1), too.
> >
> > I am going to send these patches:
> >
> > (a) Add CodeGenModule::addUsedOrCompilerUsedGlobal (which uses
> > llvm.compiler.used for ELF and llvm.used for the others). Migrate some
> > addUsedGlobal call sites to use addUsedOrCompilerUsedGlobal.
> > (b) Add __attribute__((retain))
> > (c) Change llvm.used to use SHF_GNU_RETAIN if integrated assembler or
> > binutils>=2.36
> >
> > Currently llvm.used/llvm.compiler.used should have no difference on
> > ELF, so (a) & (b) do not affect users who don't use 'retain'.
> >
> > (c) will change the binary format representation of llvm.used, so
> > there is some risk if the consumer is not prepared for multiple
> > sections of the same name (which means they already break with
> > -fno-unique-section-names, but the option is rare).
> > On very large C/C++ projects, llvm.used has usually 0 or 1 element.
> > ObjC can have multiple llvm.used but that should work. So if there is
> > risk, the risk for other frontends.
> > I don't see a way to avoid that, but they can switch to
> > llvm.compiler.used.
> >
> > Non-ELF users should not observe anything different.
> >
> > > On Wed, Feb 24, 2021 at 1:09 AM Fāng-ruì Sòng via cfe-dev <cfe-
> > [hidden email]> wrote:
> > >>
> > >> On 2021-02-24, Fāng-ruì Sòng wrote:
> > >> >Currently __attribute__((used)) lowers to llvm.used.
> > >> >
> > >> >* On Mach-O, a GlobalObject in llvm.used gets the S_ATTR_NO_DEAD_STRIP
> > >> >attribute, which prevents linker GC (dead stripping).
> > >> >* On COFF, a non-local-linkage GlobalObject[1] in llvm.used gets the
> > >> >/INCLUDE: linker option (similar to ELF `ld -u`), which prevents
> > >> >linker GC.
> > >> >  It should be possible to work with local linkage GlobalObject's as
> > >> >well but that will require a complex COMDAT dance.
> > >> >* On ELF, a global object llvm.used can be discarded by
> > >> >ld.bfd/gold/ld.lld --gc-sections.
> > >> >  (If the section is a C identifier name, __start_/__stop_ relocations
> > >> >from a live input section can retain the section, even if its defined
> > >> >symbols are not referenced. [2] .
> > >> >  I understand that some folks use `__attribute__((used,
> > >> >section("C_ident")))` and expect the sections to be similar to GC
> > >> >roots, however,
> > >> >  non-C-identifier cases are very common, too. They don't get
> > >> >__start_/__stop_ linker magic and the sections can always be GCed.
> > >> >  )
> > >> >
> > >> >In LangRef, the description of llvm.used contains:
> > >> >
> > >> >> If a symbol appears in the @llvm.used list, then the compiler,
> > assembler, and **linker** are required to treat the symbol as if there is
> > a reference to the symbol that it cannot see (which is why they have to be
> > named). For example, if a variable has internal linkage and no references
> > other than that from the @llvm.used list, it cannot be deleted. This is
> > commonly used to represent references from inline asms and other things
> > the compiler cannot “see”, and corresponds to “attribute((used))” in GNU
> > C.
> > >> >
> > >> >Note that the "linker" part does not match the reality on ELF targets.
> > >> >It does match the reality on Mach-O and partially on COFF.
> > >> >
> > >> >llvm.compiler.used:
> > >> >
> > >> >> The @llvm.compiler.used directive is the same as the @llvm.used
> > directive, except that it only prevents the compiler from touching the
> > symbol. On targets that support it, this allows an **intelligent linker to
> > optimize references to the symbol without being impeded** as it would be
> > by @llvm.used.
> > >> >
> > >> >Note that this explicitly mentions linker GC, so this appears to be
> > >> >the closest thing to __attribute__((used)) on ELF.
> > >> >However, LangRef also says:
> > >> >
> > >> >> This is a rare construct that should only be used in rare
> > circumstances, and should not be exposed to source languages.
> > >> >
> > >> >
> > >> >
> > >> >My goal is to implement __attribute__((retain)) (which will be in GCC
> > >> >11) on ELF. GCC folks think that 'used' and 'retain are orthogonal.
> > >> >(see
> > https://urldefense.com/v3/__https://reviews.llvm.org/D96838*2578127__;Iw!!
> > JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz-sSt4Y-
> > y3hXRPvXMA$ )
> > >> >
> > >> >Shall we
> > >> >
> > >> >1. Lift the source language restriction on llvm.compiler.used and
> > >> >change __attribute__((used)) to use llvm.compiler.used on ELF.
> > >>
> > >> It is too late here and I did not think of it clearly;-)
> > >>
> > >> Clarify:
> > >>
> > >> 1. Lift the source language restriction on llvm.compiler.used, let
> > llvm.used use SHF_GNU_RETAIN on ELF, and change __attribute__((used)) to
> > use llvm.compiler.used on ELF.
> > >>
> > >>
> > >> __attribute__((retain)) has semantics which are not described by
> > >> llvm.used/llvm.compiler.used.  To facilitate linker GC,
> > __attribute__((retain))
> > >> causes the section to be placed in a unique section. The separate
> > section
> > >> behavior can be undesired in some cases (e.g. poorly written Linux
> > kernel linker
> > >> scripts which expect one section per name).
> > >>
> > >> So in the -fno-function-sections -fno-data-sections case, a retained
> > >> function/variable does not cause the whole .text/.data/.rodata to be
> > retained.
> > >>
> > >> The test llvm/test/CodeGen/X86/elf-retain.ll in
> > https://urldefense.com/v3/__https://reviews.llvm.org/D96837__;!!JmoZiZGBv3
> > RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz-sSt4Y-y3igRCpu4Q$
> > >> demonstrates the behavior.  So I am not particularly clear that we
> > should use
> > >> llvm.compiler.used/llvm.used to describe __attribute__((retain)) .
> > >>
> > >> >2. Or add a metadata (like
> > https://urldefense.com/v3/__https://reviews.llvm.org/D96837)?__;!!JmoZiZGB
> > v3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz-sSt4Y-
> > y3j8yTbbsA$
> > >> >
> > >> >
> > >> >I lean to option 1 to leverage the existing mechanism.
> > >> >The downside is that clang codegen will have some target inconsistency
> > >> >(llvm.compiler.used on ELF while llvm.used on others).
> > >> >
> > >> >
> > >> >
> > >> >[1]: The implementation additionally allows GlobalAlias.
> > >> >[2]: See https://urldefense.com/v3/__https://maskray.me/blog/2021-01-
> > 31-metadata-sections-comdat-and-shf-link-
> > order__;!!JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9
> > Gz-sSt4Y-y3jIbWqo9A$
> > >> >"C identifier name sections" for details.
> > >> _______________________________________________
> > >> cfe-dev mailing list
> > >> [hidden email]
> > >> https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> > bin/mailman/listinfo/cfe-
> > dev__;!!JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz
> > -sSt4Y-y3gvE5g2Qg$
> >
> >
> >
> > --
> > 宋方睿
> > _______________________________________________
> > cfe-dev mailing list
> > [hidden email]
> > https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> > bin/mailman/listinfo/cfe-
> > dev__;!!JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz
> > -sSt4Y-y3gvE5g2Qg$



--
宋方睿
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: __attribute__((retain)) && llvm.used/llvm.compiler.used

Manas via cfe-dev
> > > (c) Change llvm.used to use SHF_GNU_RETAIN if integrated assembler or
> > > binutils>=2.36
> >
> > I am curious how you intend to check if binutils>=2.36.  This is not
> > something you can decide when the compiler is built.
> > --paulr
>
> -fintegrated-as can use SHF_GNU_RETAIN. GNU ld not recognizing
> SHF_GNU_RETAIN just ignores the flag (ELF spirit: ignore what you
> don't understand).
> -fno-integrated-as users (rare) can use -fbinutils-version=2.36

Thanks! Was not aware of the -fbinutils-version option.
--paulr

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: __attribute__((retain)) && llvm.used/llvm.compiler.used

Manas via cfe-dev
In reply to this post by Manas via cfe-dev
On 24 Feb 2021, at 13:39, David Blaikie wrote:

> (best to include folks from previous conversations in threads -
> sometimes
> we can't all keep up to date with all the threads happening - so I've
> added
> John McCall here, and echristo since he might have some thoughts on
> this
> too)
>
> I'd lean towards (1) too myself - give the LLVM constructs consistent
> semantics, and deal with the platform differences in the frontend
> during
> the mapping down to LLVM.

I agree that we should go with (1) and give the LLVM construct
consistent semantics to the best of our ability.

John.

>
> On Wed, Feb 24, 2021 at 1:09 AM Fāng-ruì Sòng via cfe-dev <
> [hidden email]> wrote:
>
>> On 2021-02-24, Fāng-ruì Sòng wrote:
>>> Currently __attribute__((used)) lowers to llvm.used.
>>>
>>> * On Mach-O, a GlobalObject in llvm.used gets the
>>> S_ATTR_NO_DEAD_STRIP
>>> attribute, which prevents linker GC (dead stripping).
>>> * On COFF, a non-local-linkage GlobalObject[1] in llvm.used gets the
>>> /INCLUDE: linker option (similar to ELF `ld -u`), which prevents
>>> linker GC.
>>>  It should be possible to work with local linkage GlobalObject's as
>>> well but that will require a complex COMDAT dance.
>>> * On ELF, a global object llvm.used can be discarded by
>>> ld.bfd/gold/ld.lld --gc-sections.
>>>  (If the section is a C identifier name, __start_/__stop_
>>> relocations
>>> from a live input section can retain the section, even if its
>>> defined
>>> symbols are not referenced. [2] .
>>>  I understand that some folks use `__attribute__((used,
>>> section("C_ident")))` and expect the sections to be similar to GC
>>> roots, however,
>>>  non-C-identifier cases are very common, too. They don't get
>>> __start_/__stop_ linker magic and the sections can always be GCed.
>>>  )
>>>
>>> In LangRef, the description of llvm.used contains:
>>>
>>>> If a symbol appears in the @llvm.used list, then the compiler,
>> assembler, and **linker** are required to treat the symbol as if
>> there is a
>> reference to the symbol that it cannot see (which is why they have to
>> be
>> named). For example, if a variable has internal linkage and no
>> references
>> other than that from the @llvm.used list, it cannot be deleted. This
>> is
>> commonly used to represent references from inline asms and other
>> things the
>> compiler cannot “see”, and corresponds to “attribute((used))”
>> in GNU C.
>>>
>>> Note that the "linker" part does not match the reality on ELF
>>> targets.
>>> It does match the reality on Mach-O and partially on COFF.
>>>
>>> llvm.compiler.used:
>>>
>>>> The @llvm.compiler.used directive is the same as the @llvm.used
>> directive, except that it only prevents the compiler from touching
>> the
>> symbol. On targets that support it, this allows an **intelligent
>> linker to
>> optimize references to the symbol without being impeded** as it would
>> be by
>> @llvm.used.
>>>
>>> Note that this explicitly mentions linker GC, so this appears to be
>>> the closest thing to __attribute__((used)) on ELF.
>>> However, LangRef also says:
>>>
>>>> This is a rare construct that should only be used in rare
>> circumstances, and should not be exposed to source languages.
>>>
>>>
>>>
>>> My goal is to implement __attribute__((retain)) (which will be in
>>> GCC
>>> 11) on ELF. GCC folks think that 'used' and 'retain are orthogonal.
>>> (see https://reviews.llvm.org/D96838#2578127)
>>>
>>> Shall we
>>>
>>> 1. Lift the source language restriction on llvm.compiler.used and
>>> change __attribute__((used)) to use llvm.compiler.used on ELF.
>>
>> It is too late here and I did not think of it clearly;-)
>>
>> Clarify:
>>
>> 1. Lift the source language restriction on llvm.compiler.used, let
>> llvm.used use SHF_GNU_RETAIN on ELF, and change __attribute__((used))
>> to
>> use llvm.compiler.used on ELF.
>>
>>
>> __attribute__((retain)) has semantics which are not described by
>> llvm.used/llvm.compiler.used.  To facilitate linker GC,
>> __attribute__((retain))
>> causes the section to be placed in a unique section. The separate
>> section
>> behavior can be undesired in some cases (e.g. poorly written Linux
>> kernel
>> linker
>> scripts which expect one section per name).
>>
>> So in the -fno-function-sections -fno-data-sections case, a retained
>> function/variable does not cause the whole .text/.data/.rodata to be
>> retained.
>>
>> The test llvm/test/CodeGen/X86/elf-retain.ll in
>> https://reviews.llvm.org/D96837
>> demonstrates the behavior.  So I am not particularly clear that we
>> should
>> use
>> llvm.compiler.used/llvm.used to describe __attribute__((retain)) .
>>
>>> 2. Or add a metadata (like https://reviews.llvm.org/D96837)?
>>>
>>>
>>> I lean to option 1 to leverage the existing mechanism.
>>> The downside is that clang codegen will have some target
>>> inconsistency
>>> (llvm.compiler.used on ELF while llvm.used on others).
>>>
>>>
>>>
>>> [1]: The implementation additionally allows GlobalAlias.
>>> [2]: See
>> https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order
>>> "C identifier name sections" for details.
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: __attribute__((retain)) && llvm.used/llvm.compiler.used

Manas via cfe-dev
In reply to this post by Manas via cfe-dev
On Wed, Feb 24, 2021 at 11:03 AM Fāng-ruì Sòng <[hidden email]> wrote:

>
> On Wed, Feb 24, 2021 at 10:40 AM David Blaikie <[hidden email]> wrote:
> >
> > (best to include folks from previous conversations in threads - sometimes we can't all keep up to date with all the threads happening - so I've added John McCall here, and echristo since he might have some thoughts on this too)
> >
> > I'd lean towards (1) too myself - give the LLVM constructs consistent semantics, and deal with the platform differences in the frontend during the mapping down to LLVM.
>
> I chatted with Saleem Abdulrasool, who is in favor of (1), too.
>
> I am going to send these patches:

Implemented the idea. Sent:

> (a) Add CodeGenModule::addUsedOrCompilerUsedGlobal (which uses
> llvm.compiler.used for ELF and llvm.used for the others). Migrate some
> addUsedGlobal call sites to use addUsedOrCompilerUsedGlobal.

https://reviews.llvm.org/D97446

> (b) Add __attribute__((retain))

https://reviews.llvm.org/D97447

> (c) Change llvm.used to use SHF_GNU_RETAIN if integrated assembler or
> binutils>=2.36

https://reviews.llvm.org/D97448

> Currently llvm.used/llvm.compiler.used should have no difference on
> ELF, so (a) & (b) do not affect users who don't use 'retain'.
>
> (c) will change the binary format representation of llvm.used, so
> there is some risk if the consumer is not prepared for multiple
> sections of the same name (which means they already break with
> -fno-unique-section-names, but the option is rare).
> On very large C/C++ projects, llvm.used has usually 0 or 1 element.
> ObjC can have multiple llvm.used but that should work. So if there is
> risk, the risk for other frontends.
> I don't see a way to avoid that, but they can switch to llvm.compiler.used.
>
> Non-ELF users should not observe anything different.



> > On Wed, Feb 24, 2021 at 1:09 AM Fāng-ruì Sòng via cfe-dev <[hidden email]> wrote:
> >>
> >> On 2021-02-24, Fāng-ruì Sòng wrote:
> >> >Currently __attribute__((used)) lowers to llvm.used.
> >> >
> >> >* On Mach-O, a GlobalObject in llvm.used gets the S_ATTR_NO_DEAD_STRIP
> >> >attribute, which prevents linker GC (dead stripping).
> >> >* On COFF, a non-local-linkage GlobalObject[1] in llvm.used gets the
> >> >/INCLUDE: linker option (similar to ELF `ld -u`), which prevents
> >> >linker GC.
> >> >  It should be possible to work with local linkage GlobalObject's as
> >> >well but that will require a complex COMDAT dance.
> >> >* On ELF, a global object llvm.used can be discarded by
> >> >ld.bfd/gold/ld.lld --gc-sections.
> >> >  (If the section is a C identifier name, __start_/__stop_ relocations
> >> >from a live input section can retain the section, even if its defined
> >> >symbols are not referenced. [2] .
> >> >  I understand that some folks use `__attribute__((used,
> >> >section("C_ident")))` and expect the sections to be similar to GC
> >> >roots, however,
> >> >  non-C-identifier cases are very common, too. They don't get
> >> >__start_/__stop_ linker magic and the sections can always be GCed.
> >> >  )
> >> >
> >> >In LangRef, the description of llvm.used contains:
> >> >
> >> >> If a symbol appears in the @llvm.used list, then the compiler, assembler, and **linker** are required to treat the symbol as if there is a reference to the symbol that it cannot see (which is why they have to be named). For example, if a variable has internal linkage and no references other than that from the @llvm.used list, it cannot be deleted. This is commonly used to represent references from inline asms and other things the compiler cannot “see”, and corresponds to “attribute((used))” in GNU C.
> >> >
> >> >Note that the "linker" part does not match the reality on ELF targets.
> >> >It does match the reality on Mach-O and partially on COFF.
> >> >
> >> >llvm.compiler.used:
> >> >
> >> >> The @llvm.compiler.used directive is the same as the @llvm.used directive, except that it only prevents the compiler from touching the symbol. On targets that support it, this allows an **intelligent linker to optimize references to the symbol without being impeded** as it would be by @llvm.used.
> >> >
> >> >Note that this explicitly mentions linker GC, so this appears to be
> >> >the closest thing to __attribute__((used)) on ELF.
> >> >However, LangRef also says:
> >> >
> >> >> This is a rare construct that should only be used in rare circumstances, and should not be exposed to source languages.
> >> >
> >> >
> >> >
> >> >My goal is to implement __attribute__((retain)) (which will be in GCC
> >> >11) on ELF. GCC folks think that 'used' and 'retain are orthogonal.
> >> >(see https://reviews.llvm.org/D96838#2578127)
> >> >
> >> >Shall we
> >> >
> >> >1. Lift the source language restriction on llvm.compiler.used and
> >> >change __attribute__((used)) to use llvm.compiler.used on ELF.
> >>
> >> It is too late here and I did not think of it clearly;-)
> >>
> >> Clarify:
> >>
> >> 1. Lift the source language restriction on llvm.compiler.used, let llvm.used use SHF_GNU_RETAIN on ELF, and change __attribute__((used)) to use llvm.compiler.used on ELF.
> >>
> >>
> >> __attribute__((retain)) has semantics which are not described by
> >> llvm.used/llvm.compiler.used.  To facilitate linker GC, __attribute__((retain))
> >> causes the section to be placed in a unique section. The separate section
> >> behavior can be undesired in some cases (e.g. poorly written Linux kernel linker
> >> scripts which expect one section per name).
> >>
> >> So in the -fno-function-sections -fno-data-sections case, a retained
> >> function/variable does not cause the whole .text/.data/.rodata to be retained.
> >>
> >> The test llvm/test/CodeGen/X86/elf-retain.ll in https://reviews.llvm.org/D96837
> >> demonstrates the behavior.  So I am not particularly clear that we should use
> >> llvm.compiler.used/llvm.used to describe __attribute__((retain)) .
> >>
> >> >2. Or add a metadata (like https://reviews.llvm.org/D96837)?
> >> >
> >> >
> >> >I lean to option 1 to leverage the existing mechanism.
> >> >The downside is that clang codegen will have some target inconsistency
> >> >(llvm.compiler.used on ELF while llvm.used on others).
> >> >
> >> >
> >> >
> >> >[1]: The implementation additionally allows GlobalAlias.
> >> >[2]: See https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order
> >> >"C identifier name sections" for details.
> >> _______________________________________________
> >> cfe-dev mailing list
> >> [hidden email]
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> --
> 宋方睿



--
宋方睿
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev