[PATCH] D96838: Add GNU attribute 'retain'

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D96838#2578127 <https://reviews.llvm.org/D96838#2578127>, @rjmccall wrote:

> In D96838#2578101 <https://reviews.llvm.org/D96838#2578101>, @MaskRay wrote:
>
>> In D96838#2578097 <https://reviews.llvm.org/D96838#2578097>, @rjmccall wrote:
>>
>>> In D96838#2578083 <https://reviews.llvm.org/D96838#2578083>, @MaskRay wrote:
>>>
>>>> In D96838#2578073 <https://reviews.llvm.org/D96838#2578073>, @rjmccall wrote:
>>>>
>>>>> GCC 11 hasn't been released yet, so can we still engage with GCC about the semantics of this attribute?  This is a very low-level attribute, and I don't understand why it was made separate instead of just having `used` add the appropriate section flag on targets that support it.
>>>>
>>>> GCC did overload `used` with the linker garbage collection semantics. Then after discussions (e.g. https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565478.html) they decided to pick the earliest suggestion: add `retain`.
>>>>
>>>> This makes sense to me: `used` can emit a function which is only used by inline assembly, but the user intention can still be that the whole thing can be GCable.
>>>
>>> There's definitely some merit to distinguishing the cases here — `used` doesn't just force the object to be emitted, it also forces the compiler to treat it as if there might be accesses to the variable / function that it can't see.  Thus, for example, a non-const `used` variable has to be assumed to be potentially mutated in arbitrary ways.  I guess my concern is that this new attribute still doesn't feel like it covers the use cases very well, especially because `used` does have long-established semantics of affecting the linker on non-ELF targets.  Basically, to get "full strength" semantics that affect the compiler and linker on all targets, you have to add a new attribute;
>>
>> Yes.
>>
>>> to get "partial strength" semantics that only affect the compiler, you can use the old attribute on ELF, but there's no way to spell it on non-ELF; and if you wanted to get "weak" semantics (e.g. to force the symbol to be preserved through linking without broadly disabling the optimizer), there's no way to spell that anywhere.
>>
>> The semantics can be represented on non-ELF, as long as the binary format supports multiple sections of the same name.
>
> My concern is less whether the semantics are implementable and more whether there's a way of requesting them in the source language.  `attribute((used))` is expected to prevent link-time stripping on Mach-O and PE/COFF.  We can't just change the long-accepted semantics of the existing attribute after something like 20 years; this is documented behavior.
>
> That said, I can understand why GCC is reluctant to make `attribute((used))` alone start preventing the linker from stripping symbols that it's been able to strip for years.  So I guess really the attribute just has to be understood to have a different meaning on different targets because of this historical divergence.  This seems like something we need to document in the manual.

I have documented the behaviors in `clang/include/clang/Basic/AttrDocs.td`. Do you have suggestions on the wording?

> If we wanted to implement the PE/COFF precision improvement, so that `used` only affected one specific declaration, that seems like something we could probably reasonably do, since that behavior is not documented (and may be inconsistent between linkages anyway, if I understand you right).




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96838/new/

https://reviews.llvm.org/D96838