[PATCH] D132977: [HLSL] Call global constructors inside entry

[Chris Bieneman via Phabricator via cfe-commits]

beanz added inline comments.


================
Comment at: clang/lib/CodeGen/CGHLSLRuntime.cpp:151
+  llvm::Module &M = CGM.getModule();
+  const auto *GlobalCtors = M.getNamedGlobal("llvm.global_ctors");
+  if (!GlobalCtors)
----------------
python3kgae wrote:
> beanz wrote:
> > python3kgae wrote:
> > > Don't need to generate CtorCalls for lib profile in clang codeGen.
> > > Have to do this when linking anyway.
> > Are you sure? The global constructors contain the `createHandle` calls for resources, and DXC does currently generate those inside shader entries for lib shaders.
> > 
> > I'm sure we're not generating those _correctly_ with this change, but I think we still need the constructor calls inside any function annotated with the `[shader(...)]` attribute.
> I saw dxc did call ctor for all entries. Maybe to match the behavior, we need to do the same thing.
> But I don't understand why we must do that except to match what dxc does.
> Maybe we can also have a test for lib profile to make understanding things easier?
I can (and should) add a library shader test too.

In addition to the cases where DXC generates global constructors, we need them in clang in more cases, because I'm using global constructors to reduce the scope of changes HLSL needs in CodeGen.

In the case of global resource variables (as shown in the test in this PR), DXC generates the handle creation calls with a bunch of custom code in clang CodeGen, and inserts that code into the entry functions.

To avoid needing special code for handle creation in Clang, I've put handle creation calls inside the constructors for the resource object. For global definitions, the constructors then get called by the global initialization function automatically, which we can inline into the entry.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132977