[clang] [llvm] [Clang][AIX] Add -mloadtime-comment-vars flag to preserve identifying variables (PR #187986)
Aaron Ballman via llvm-commits
llvm-commits at lists.llvm.org
Wed Sep 23 05:07:05 PDT 2026
================
@@ -15460,6 +15461,108 @@ void Sema::CheckThreadLocalForLargeAlignment(VarDecl *VD) {
}
}
+/// Process a variable definition whose mangled name may be listed in
+/// '-mloadtime-comment-vars=': attach an implicit attribute to supported
+/// string variables so CodeGen preserves them as loadtime identifying
+/// strings, and warn when a named variable cannot be preserved.
+static void processForLoadTimeCommentVar(Sema &S, VarDecl *VD) {
+ // Declarations that cannot be name-matched are silently skipped: an
+ // automatic variable has no symbol of its own, and neither does a template
+ // pattern (only its specializations do, and those are processed
+ // separately). Only definitions are considered.
+ if (VD->hasLocalStorage())
+ return;
+ if (VD->isTemplated())
+ return;
+ if (VD->isThisDeclarationADefinition(S.Context) != VarDecl::Definition)
+ return;
+
+ // Only plain `char` pointers/arrays with an initializer are supported; a
+ // matched variable of any other form (int, struct, wide or explicitly
+ // signed/unsigned character types, no initializer, ...) is silently
+ // ignored.
----------------
AaronBallman wrote:
I'm wondering why silently ignored? If a user went to the trouble of coming up with a valid mangled name, it seems like they would expect that to do something and so silently ignoring what they specified will be hard for them to debug. Is my intuition wrong?
(Additionally, I wonder about why we would silently ignore an invalid mangled name too; mangling is not easy to do by hand and so there's a reasonable chance for the user to have typos, so I would have imagined they'd want to know about this scenario too. But it does seem somewhat more defensible if the variable is conditionally defined (e.g., wrapped in `#ifndef NDEBUG` or something) so I'm not strongly opposed, just raising the debuggability question.)
https://github.com/llvm/llvm-project/pull/187986
More information about the llvm-commits
mailing list