AlexVlx wrote: > The third argument here is like for llvm.used, it's a way to associate the > entry with a global or function. If the corresponding global or function is > omitted from the output then the entry will be removed. It isn't used for > anything at run time. So I think there should be a consistent story between > llvm.used and llvm.global_[cd]tors.
> The third argument here is like for llvm.used, it's a way to associate the > entry with a global or function. If the corresponding global or function is > omitted from the output then the entry will be removed. It isn't used for > anything at run time. So I think there should be a consistent story between > llvm.used and llvm.global_[cd]tors. > The third argument here is like for llvm.used, it's a way to associate the > entry with a global or function. If the corresponding global or function is > omitted from the output then the entry will be removed. It isn't used for > anything at run time. So I think there should be a consistent story between > llvm.used and llvm.global_[cd]tors. IMHO, and I could be wrong, the key challenge that we have both here and re `used`, is that for these we'd really want a truly generic/flat/everywhere-usable pointer type - it can be casted to / from any other AS etc., essentially a DONTCARE in IR. An unqualified ptr should probably have been that, rather than an implicitly AS0 ptr. It's impossible for Clang to query that from a target today (AFAICT), the only close equivalent being asking for the target's AS corresponding to `LangAS::Default`, and hoping that it's a sane mapping. Emitting these unconditionally as unqualified `ptr`s as is bothers me because we're calling the elements out as globals but then not acting accordingly, and because unqualified actually means AS0, which then relies on the target not being funky with AS0 (some targets are). Perhaps an alternative is to tweak LangRef wording to say that that these are always emitted as unqualified ptrs, and that their ephemeral nature implies that their AS is meaningless? https://github.com/llvm/llvm-project/pull/93914 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
