[PATCH] D54774: [GlobalOpt] Optimize comdat dynamic initializers on Windows

[John McCall via Phabricator via llvm-commits]

rjmccall added inline comments.


================
Comment at: llvm/lib/Transforms/Utils/CtorUtils.cpp:116
+  bool AssumeComdatInitializers =
+      Triple(M.getTargetTriple()).isWindowsMSVCEnvironment();
+
----------------
rnk wrote:
> rjmccall wrote:
> > efriedma wrote:
> > > If the IR doesn't have enough information to distinguish between the Microsoft and Itanium ABI cases, we should extend the IR to contain more information.  Checking the triple means we're depending on semantic guarantees which are not documented in LangRef, and many not apply to non-C++ languages.
> > I agree with Eli.  This is clearly a frontend-originated guarantee, not a target-wide guarantee, and should be reflected in the IR.
> For platforms with comdats, I wanted to push this same idea through the Itanium C++ ABI. It completely eliminates the need for guard variables for initializers of variables with vague linkage, although only if they are hidden, so other DSOs don't try to initialize them.
> 
> What do you think of some kind of global named metadata node for this? This is such a complicated guarantee to express, I've tried and failed to write it down concisely three times. `!llvm.assume_comdat_ctors`? `!llvm.comdat_initializers = !{i32 0, i32 1}`? I like "comdat_initializers".
> For platforms with comdats, I wanted to push this same idea through the Itanium C++ ABI. It completely eliminates the need for guard variables for initializers of variables with vague linkage, although only if they are hidden, so other DSOs don't try to initialize them.

Okay, but it's still not a target-wide thing, it's a rule of a specific language ABI.  That's a higher level of abstraction than LLVM IR and should be opt-in on a variable-by-variable basis.

> This is such a complicated guarantee to express, I've tried and failed to write it down concisely three times.

"If this definition of the global variable is chosen by the linker, there is an associated global constructor function that will also be chosen by the linker, and it is undefined behavior if any other global constructor accesses the variable before the associated constructor runs."  I'd call it `comdat_global_ctor`, but the "comdat" in the name is just suggestive, not a core aspect of the semantics.


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

https://reviews.llvm.org/D54774