-dump-ir should print disassembly of downstream target SPIR-V IR for embedded blobs.

[cheneym2]

-dump-ir should print disassembly of downstream target IR for embedded blobs

This request is for SPIR-V in particular.

At least one slang-test should demonstrate the capability by using "filecheck" for SPIR-V in a precompiled module, looking at the "-dump-ir" output and looking for one or two key ops, e.g. "OpCapability Linkage" and "OpDecorate... LinkageAttributes ... Export" would be good ones to check for.

[cheneym2]

I don't know offhand the correct place to add -dump-ir support which would show embedded downstream IR and decorations, but this hack shows you what the current IR dumping logic does with the decorations:

diff --git a/source/slang/slang-compiler-tu.cpp b/source/slang/slang-compiler-tu.cpp
index 8bfe9a9a..362f786e 100644
--- a/source/slang/slang-compiler-tu.cpp
+++ b/source/slang/slang-compiler-tu.cpp
@@ -212,6 +212,9 @@ Module::precompileForTarget(SlangCompileTarget target, slang::IBlob** outDiagnos
     builder.setInsertInto(module);
     builder.emitEmbeddedDownstreamIR(targetReq->getTarget(), blob);
+
    module->getModuleInst()->dump();
+
     return SLANG_OK;
 }

$ build/Release/bin/slangc tests/library/export-library-generics.slang -o my.slang-module -target spirv -embed-downstream-ir

...
[availableInDownstreamIR(6 : Int)]
[public]
[export("_SR29export_2Dxlibrary_2Dxgenerics21normalFuncUsesGenericp1pi_ii")]
[nameHint("normalFuncUsesGeneric")]
func %normalFuncUsesGeneric	: Func(Int, Int)
{
...
EmbeddedDownstreamIR(6 : Int, <binary blob>)

[cheneym2]

The expectation is that the logic that prints out the "EmbeddedDownstreamIR" instruction is updated. Right now, it just shows an ID operand indicating SPIRV (6), followed by the word "binary blob" that represents the OpBlobLit operand. But ideally the blob would show up as disassembled SPIR-V if the target operand is SLANG_SPIRV (6).

I don't think it's a trivial task, hence the 3 day estimate.

It's an additional task to make it so that -dump-ir shows this post-precompileForTarget output, since "LOWER-TO-IR" is too early. I didn't initially think of that complication when writing the github issue. Maybe the estimate should be 4 days.

Filecheck should naturally be able to check for embedded SPIRV operations then.