JonChesterfield added a comment. It looks deeply wrong to be marking global as either llvm.used or llvm.compiler.used based on the output file format. It should be based on the (purpose of) the global.
In D97446#3241142 <https://reviews.llvm.org/D97446#3241142>, @rnk wrote: > This change was implemented so that llvm.used could prevent section GC on > ELF, to make its semantics consistent with llvm.used on COFF and MachO. > Essentially, llvm.used behaves differently on ELF now so to prevent behavior > changes for users of `__attribute__((used))`, it was migrated to > `llvm.compiler.used` on ELF targets. This is consistent with GCC's behavior. Is this sentence inverted? llvm.used should prevent sections from being discarded. If it doesn't at present, that's a bug in the linker. llvm.compiler.used should generally be discarded by whatever part of the compiler wanted the variable, but if it makes it to the linker, the linker should throw it away. Because it was only used by the compiler. It's possible some users marked things as 'used' but wanted them thrown away, but it seems more likely that users weren't using gc-sections if it broke their application. by throwing away things they asked to keep. > This should only change behavior for you if you depend on the details of the > LLVM IR being emitted, or perhaps if you use LTO, where GlobalOpt will behave > differently. I don't think these use cases are as important as consistent ELF > section GC behavior. > > So, apologies for changing the LLVM IR emitted for this attribute, but I > think it's unlikely we will change our minds and revert this a year later. I'm hopeful I can change your minds now. The current modelling in the compiler doesn't match the stated intent. In D97446#3241195 <https://reviews.llvm.org/D97446#3241195>, @MaskRay wrote: > llvm.compiler.used hasn't been changed. True, but attribute((used)) has. > The text focuses on the semantics, and for practical reasons refers to the > toolchain support. > Before GCC 11/binutils 2.36 there was just no portable way making a > definition not discarded by ld --gc-sections. Sure there was. Don't pass gc-sections to the linker, or don't compile with ffunction-sections to get a close approximation. >> edit: Would making attribute((used)) imply attribute((retain)) on elf >> targets achieve the objective of this patch without breaking code that >> expects 'used' to mean "don't throw this away"? > > This would make semantics less orthogonal and incompatible with GCC. > On COFF and Mach-O, there have been Clang-specific (not GCC) use cases > relying on attribute((used)) implying GC roots. > On ELF, there was none before the toolchain support. > > Every llvm.used usage I can find in the wild does intend to have the GC > semantics, and not having it on ELF was actually a bug and has been fixed by > the patch series. I'm absolutely sure that people mark things as attribute((used)) to stop the toolchain discarding them. I think we're in agreement there, but differ in our assessment of popularity of gc-sections. Are we missing a category here? llvm.compiler.used <- the compiler uses the global, and may discard it. If it doesn't, the linker should discard it llvm.linker.used <- the linker uses this global, and may discard it. The compiler should leave it alone aside from passing it to the linker llvm.used <- some unspecified thing uses the global, the compiler and linker should leave it alone aside from embedding it in the linked output If we have to map 'attribute((used))' onto the new llvm.linker.used and 'attribute((retain))' onto llvm.used that's a shame, but at least it keeps the naming weirdness localised to the language front end. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D97446/new/ https://reviews.llvm.org/D97446 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
