diff options
| author | Tim Foley <tfoleyNV@users.noreply.github.com> | 2019-11-06 18:43:33 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-11-06 18:43:33 -0800 |
| commit | fedda2e5342d3bfbdbbdd3ca232b3f69fff81ef7 (patch) | |
| tree | e6edb884d601c5f71ac70370904b2b04274a518f /source/slang/slang-compiler.h | |
| parent | 7a877c380c3c84d03326e6fb982f85547d0bd338 (diff) | |
Add basic support for entry points in `.slang-lib` files. (#1112)
* Add basic support for entry points in `.slang-lib` files.
The basic idea here is that when writing out a `.slang-lib` file based on a compile request, we include new sections in the generated RIFF that represent the entry points that were requested. The entry-point information is serialized in an entirely ad hoc fashion (a future change might clean it up to use the `OffsetContainer` machinery), and contains the name, profile, and mangled symbol name of an entry point.
When deserializing this information, we create a list of "extra" entry points that gets attached to the front-end compile requests. These "extra" entry points get turned into `EntryPoint` objects at the same place in the code that entry points specified on the command line or via API would be checked, but the extra entry points bypass the semantic checking and just create "dummy" `EntryPoint` objects.
Aside: the ability for a compile request to end up with entry points that weren't originally specified via API or command-line is not new. We already had support for compiling a translation unit with entry points entirely specified via `[shader(...)]` attributes, and this new support tries to function similarly.
Because the "dummy" entry points don't retain AST-level information, several parts of the code have been modified to defensively check for `EntryPoint` objects without a matching AST declaration, and skip over them.
The main place where this creates a problem is paramete binding, where ignoring the dummy entry point is appropriate since we currently assume linked-in library code has been laid out manually.
One small cleanup here is that the `-r` command-line flag and the `spAddLibraryReference` API functio now bottleneck through a common routine to do their work, so that they both gain the new behavior without needing copy-paste programming.
In order to keep the existing test case for library linking with entry points working, I had to add a flag to the `render-test` tool so that it can skip specifying entry point names as part of the compile request it creates. In that case it must instead assume that the entry points will be added to the compile request via other means. This logic is a bit magical, and hints that we should be looking for other ways to expose the library linking functionality over time.
* fixup: remove alignment assertion
Diffstat (limited to 'source/slang/slang-compiler.h')
| -rw-r--r-- | source/slang/slang-compiler.h | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/source/slang/slang-compiler.h b/source/slang/slang-compiler.h index 2819269b5..e3fbf57f6 100644 --- a/source/slang/slang-compiler.h +++ b/source/slang/slang-compiler.h @@ -695,6 +695,13 @@ namespace Slang Name* name, Profile profile); + /// Create a dummy `EntryPoint` that stands in for a serialized entry point + static RefPtr<EntryPoint> createDummyForDeserialize( + Linkage* linkage, + Name* name, + Profile profile, + String mangledName); + /// Get the number of existential type parameters for the entry point. Index getSpecializationParamCount() SLANG_OVERRIDE; @@ -752,6 +759,9 @@ namespace Slang // DeclRef<FuncDecl> m_funcDeclRef; + /// The mangled name of the entry point function + String m_mangledName; + SpecializationParams m_genericSpecializationParams; SpecializationParams m_existentialSpecializationParams; @@ -1445,6 +1455,17 @@ namespace Slang Name* m_defaultModuleName = nullptr; + /// An "extra" entry point that was added via a library reference + struct ExtraEntryPointInfo + { + Name* name; + Profile profile; + String mangledName; + }; + + /// A list of "extra" entry points added via a library reference + List<ExtraEntryPointInfo> m_extraEntryPoints; + private: /// A component type that includes only the global scopes of the translation unit(s) that were compiled. RefPtr<ComponentType> m_globalComponentType; |
