Revise new COM-lite API (#1007)

* Revise new COM-lite API

This change revises the "COM-lite" API that was recently introduced to try to streamline it and introduce some missing central/base concepts.

The central new abstraction in the API is the notion of a "component type," which is a unit of shader code composition. A component type can have:

* IR code for some number of functions/types/etc.
* Zero or more global shader parameters
* Zero or more "entry point" functions at which execution can start
* Zero or more "specialization" parameters (types or values that must be filled in before kernel code can be generated)
* Zero or more "requirements" (dependencies on other component types that must be satisfied before kernel code can be generated)

Both individual compiled modules, and validated entry points are then examples of component types, and we additionally define a few services that apply to all component types:

* We can take N component types and compose them to create a new component type that combines their code, shader parameters, entry points, and specialization parameters. A composed component type may also include requirements from the sub-component types, but it is also possible that by composing thing we satisfy requirements (if `A` requires `B`, and we compose `A` and `B`, then the requirement is now satisfied, and doesn't appear on the composite).

* We can take a component type with N specialization parameters, and specialize it by giving N compatible specialization arguments. The result of specialization is a new component type with zero specialization parameters. Under the right circumstances the specialzed component type will be layout compatible with the unspecialized one.

* One more example that isn't exposed in the public API today is that we can take a component with requirements and "complete" it by automatically composing it with component types that satisfy those requirements. This can be seen as a kind of linking step that pulls together the transitive closure of dependencies.

* We can query the layout for the shader parameters and entry points of a component type, for a specific target.

* We can query compiled kernel code for an entry point in a component type (for a specific target). This only works for component types with zero specialization parameters and zero requirements.

The idea is that by giving users a fairly general algebra of operations on component types, they can compose final programs in ways that meet their requirements. For example, it becomes possible to incrementally "grow" a component type to represent the global root signature for ray tracing shaders as new entry points are added, in such a way that it always stays layout-compatible with kernels that have already been compiled.

Much of the implementation work here is in implementing the unifying component type abstraction, and in particular re-writing code that used to assume a program consisted of a flat list of modules and entry points to work with a hierarchical representation that reflects the underlying algebra (e.g., with types to represent composite and specialized component types).

There's also a hidden "legacy" case of a component type to deal with some legacy compiler behaviors that can't be directly modeled on top of the simple algebra with modules and entry points.

This API is by no means feature-complete or fully developed. It is expected that we will flesh it out more when bringing up application code (e.g., Falcor) on top of the revamped API.

One notable thing that went away in this change is explicit support for "entry point groups" and notions of local root signatures (especially the Falcor-specific handling of the `shared` keyword, which a previous change turned into an explicitly supported feature). With the new "building blocks" approach, it should be possible for a DXR application to deal with local root signatures as a matter of policy (on top of the API we provide). If/when we need to provide some kind of emulation of local root signatures for Vulkan (and/or if Vulkan is extended with an explicit notion of local root signatures), we might need to revisit this choice.

* Fix debug build

There was invalid code inside an `assert()`, so the release build didn't catch it.

* fixup: warnings

* fixup: more warnings-as-errors

* fixup: review notes

* fixup: use component type visitors in place of dynamic casting

1 files changed, 69 insertions, 75 deletions

diff --git a/source/slang/slang-compiler.cpp b/source/slang/slang-compiler.cpp
index 64afef136..1c0bed065 100644
--- a/source/slang/slang-compiler.cpp
+++ b/source/slang/slang-compiler.cpp
@@ -199,10 +199,12 @@ namespace Slang
     //
 
     RefPtr<EntryPoint> EntryPoint::create(
+        Linkage*            linkage,
         DeclRef<FuncDecl>   funcDeclRef,
         Profile             profile)
     {
         RefPtr<EntryPoint> entryPoint = new EntryPoint(
+            linkage,
             funcDeclRef.GetName(),
             profile,
             funcDeclRef);
@@ -210,10 +212,12 @@ namespace Slang
     }
 
     RefPtr<EntryPoint> EntryPoint::createDummyForPassThrough(
+        Linkage*    linkage,
         Name*       name,
         Profile     profile)
     {
         RefPtr<EntryPoint> entryPoint = new EntryPoint(
+            linkage,
             name,
             profile,
             DeclRef<FuncDecl>());
@@ -221,103 +225,93 @@ namespace Slang
     }
 
     EntryPoint::EntryPoint(
+        Linkage*            linkage,
         Name*               name,
         Profile             profile,
         DeclRef<FuncDecl>   funcDeclRef)
-        : m_name(name)
+        : ComponentType(linkage)
+        , m_name(name)
         , m_profile(profile)
         , m_funcDeclRef(funcDeclRef)
     {
-        // In order for later code generation to work, we need to track what
-        // modules each entry point depends on. We will build up the dependency
-        // list here when an `EntryPoint` gets created.
-        //
-        // We know an entry point depends on the module that declared the
-        // entry-point function itself.
-        //
-        // Note: we are carefully handling the case where `module` could
-        // be null, becase of "dummy" entry points created for pass-through
-        // compilation.
+        // Collect any specialization parameters used by the entry point
         //
-        if(auto module = getModule())
+        _collectShaderParams();
+    }
+
+    Module* EntryPoint::getModule()
+    {
+        return Slang::getModule(getFuncDecl());
+    }
+
+    Index EntryPoint::getSpecializationParamCount()
+    {
+        return m_genericSpecializationParams.getCount() + m_existentialSpecializationParams.getCount();
+    }
+
+    SpecializationParam const& EntryPoint::getSpecializationParam(Index index)
+    {
+        auto genericParamCount = m_genericSpecializationParams.getCount();
+        if(index < genericParamCount)
         {
-            m_dependencyList.addDependency(module);
+            return m_genericSpecializationParams[index];
         }
-        //
-        // TODO: We also need to include the modules needed by any generic
-        // arguments in the dependency list, since in the general case they
-        // might come from modules other than the one defining the entry point.
+        else
+        {
+            return m_existentialSpecializationParams[index - genericParamCount];
+        }
+    }
 
-        // The following is a bit of a hack.
-        //
-        // Back-end code generation relies on us having computed layouts for all tagged
-        // unions that end up being used in the code, which means we need a way to find
-        // all such types that get used in a program (and the stuff it imports).
-        //
-        // For now we are assuming a tagged union type only comes into existence
-        // as a (top-level) argument for a generic type parameter, so that we
-        // can check for them here and cache them on the entry point.
+    Index EntryPoint::getRequirementCount()
+    {
+        // The only requirement of an entry point is the module that contains it.
         //
-        // A longer-term strategy might need to consider any (tagged or untagged)
-        // union types that get used inside of a module, and also take
-        // those lists into account.
+        // TODO: We will eventually want to support the case of an entry
+        // point nested in a `struct` type, in which case there should be
+        // a single requirement representing that outer type (so that multiple
+        // entry points nested under the same type can share the storage
+        // for parameters at that scope).
+
+        // Note: the defensive coding is here because the
+        // "dummy" entry points we create for pass-through
+        // compilation will not have an associated module.
         //
-        // An even longer-term strategy would be to allow type layout to
-        // be performed on IR types, so taht we don't need to have front-end
-        // code worrying about this stuff.
-        // 
-        for( auto subst = funcDeclRef.substitutions.substitutions; subst; subst = subst->outer )
+        if( auto module = getModule() )
         {
-            if( auto genericSubst = as<GenericSubstitution>(subst) )
-            {
-                for( auto arg : genericSubst->args )
-                {
-                    if( auto taggedUnionType = as<TaggedUnionType>(arg) )
-                    {
-                        m_taggedUnionTypes.add(taggedUnionType);
-                    }
-                }
-            }
+            return 1;
         }
-
-        // Collect any existential-type parameters used by the entry point
-        //
-        _collectShaderParams();
+        return 0;
     }
 
-    Module* EntryPoint::getModule()
+    RefPtr<ComponentType> EntryPoint::getRequirement(Index index)
     {
-        return Slang::getModule(getFuncDecl());
+        SLANG_UNUSED(index);
+        SLANG_ASSERT(index == 0);
+        SLANG_ASSERT(getModule());
+        return getModule();
     }
 
-    Linkage* EntryPoint::getLinkage()
+    void EntryPoint::acceptVisitor(ComponentTypeVisitor* visitor, SpecializationInfo* specializationInfo)
     {
-        return getModule()->getLinkage();
+        visitor->visitEntryPoint(this, as<EntryPointSpecializationInfo>(specializationInfo));
     }
 
-    //
-    // EntryPointGroup
-    //
-
-    RefPtr<EntryPointGroup> EntryPointGroup::create(
-        Linkage*                        linkage,
-        List<RefPtr<EntryPoint>> const& entryPoints,
-        DiagnosticSink*                 sink)
+    List<Module*> const& EntryPoint::getModuleDependencies()
     {
-        RefPtr<EntryPointGroup> group = new EntryPointGroup(linkage);
-
-        for( auto entryPoint : entryPoints )
-        {
-            for( auto module : entryPoint->getModuleDependencies() )
-            {
-                group->m_dependencyList.addDependency(module);
-            }
-            group->m_entryPoints.add(entryPoint);
-        }
+        if(auto module = getModule())
+            return module->getModuleDependencies();
 
-        group->_collectShaderParams(sink);
+        static List<Module*> empty;
+        return empty;
+    }
 
-        return group;
+    List<String> const& EntryPoint::getFilePathDependencies()
+    {
+        if(auto module = getModule())
+            return getModule()->getFilePathDependencies();
+        
+        static List<String> empty;
+        return empty;
     }
 
     //
@@ -1949,7 +1943,7 @@ SlangResult dissassembleDXILUsingDXC(
         TargetRequest*          targetReq,
         Int                     entryPointIndex)
     {
-        auto program = compileRequest->getSpecializedProgram();
+        auto program = compileRequest->getSpecializedGlobalAndEntryPointsComponentType();
         auto targetProgram = program->getTargetProgram(targetReq);
         auto backEndReq = compileRequest->getBackEndReq();
 
@@ -2020,7 +2014,7 @@ SlangResult dissassembleDXILUsingDXC(
             return result;
 
         RefPtr<BackEndCompileRequest> backEndRequest = new BackEndCompileRequest(
-            m_program->getLinkageImpl(),
+            m_program->getLinkage(),
             sink,
             m_program);
 
@@ -2083,7 +2077,7 @@ SlangResult dissassembleDXILUsingDXC(
         if (compileRequest->isCommandLineCompile)
         {
             auto linkage = compileRequest->getLinkage();
-            auto program = compileRequest->getSpecializedProgram();
+            auto program = compileRequest->getSpecializedGlobalAndEntryPointsComponentType();
             for (auto targetReq : linkage->targets)
             {
                 Index entryPointCount = program->getEntryPointCount();