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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
