From fedda2e5342d3bfbdbbdd3ca232b3f69fff81ef7 Mon Sep 17 00:00:00 2001 From: Tim Foley Date: Wed, 6 Nov 2019 18:43:33 -0800 Subject: 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 --- source/slang/slang-check-shader.cpp | 47 +++++++++++++++++++++++++++++++++++-- 1 file changed, 45 insertions(+), 2 deletions(-) (limited to 'source/slang/slang-check-shader.cpp') diff --git a/source/slang/slang-check-shader.cpp b/source/slang/slang-check-shader.cpp index 4917cc067..2ac449e83 100644 --- a/source/slang/slang-check-shader.cpp +++ b/source/slang/slang-check-shader.cpp @@ -1382,6 +1382,19 @@ static bool doesParameterMatch( } } + // Also consider entry points that were introduced via adding + // a library reference... + // + for( auto extraEntryPoint : compileRequest->m_extraEntryPoints ) + { + auto entryPoint = EntryPoint::createDummyForDeserialize( + linkage, + extraEntryPoint.name, + extraEntryPoint.profile, + extraEntryPoint.mangledName); + allComponentTypes.add(entryPoint); + } + if(allComponentTypes.getCount() > 1) { auto composite = CompositeComponentType::create( @@ -1998,9 +2011,29 @@ static bool doesParameterMatch( allComponentTypes.add(specializedGlobalComponentType); auto unspecializedGlobalAndEntryPointsComponentType = endToEndReq->getUnspecializedGlobalAndEntryPointsComponentType(); - auto entryPointCount = unspecializedGlobalAndEntryPointsComponentType->getEntryPointCount(); - for(Index ii = 0; ii < entryPointCount; ++ii) + // It is possible that there were entry points other than those specified + // vai the original end-to-end compile request. In particular: + // + // * It is possible to compile with *no* entry points specified, in which + // case the current compiler behavior is to use any entry points marked + // via `[shader(...)]` attributes in the AST. + // + // * It is possible for entry points to come into play via serialized libraries + // loaded with `-r` on the command line (or the equivalent API). + // + // We will thus draw a distinction between the "specified" entry points, + // and the "found" entry points. + // + auto specifiedEntryPointCount = endToEndReq->entryPoints.getCount(); + auto foundEntryPointCount = unspecializedGlobalAndEntryPointsComponentType->getEntryPointCount(); + + SLANG_ASSERT(foundEntryPointCount >= specifiedEntryPointCount); + + // For any entry points that were specified, we can use the specialization + // argument information provided via API or command line. + // + for(Index ii = 0; ii < specifiedEntryPointCount; ++ii) { auto& entryPointInfo = endToEndReq->entryPoints[ii]; auto unspecializedEntryPoint = unspecializedGlobalAndEntryPointsComponentType->getEntryPoint(ii); @@ -2011,6 +2044,16 @@ static bool doesParameterMatch( outSpecializedEntryPoints.add(specializedEntryPoint); } + // Any entry points beyond those that were specified up front will be + // assumed to not need/want specialization. + // + for( Index ii = specifiedEntryPointCount; ii < foundEntryPointCount; ++ii ) + { + auto unspecializedEntryPoint = unspecializedGlobalAndEntryPointsComponentType->getEntryPoint(ii); + allComponentTypes.add(unspecializedEntryPoint); + outSpecializedEntryPoints.add(unspecializedEntryPoint); + } + RefPtr composed = CompositeComponentType::create(endToEndReq->getLinkage(), allComponentTypes); return composed; } -- cgit v1.2.3