[mlir][dxsa] Add dcl_function_body and dcl_function_table by asavonic · Pull Request #134 · access-softek/llvm-project

asavonic · 2026-05-22T15:31:43Z

DX assembly programs support "virtual" inlining of subroutines by defining a set of functions that might be called for a call site.
The compiler then prepares an inlined specialization for every possible callee. The actual specialization is selected at runtime.

On DXBC level, functions are declared and identified by numbers, grouped into tables, and tables are grouped as interfaces:

// Function table for AmbientLight.
dcl_function_body fb0
dcl_function_table ft0 = { fb0 }

// Function table for DirectionalLight.
dcl_function_body fb1
dcl_function_table ft1 = { fb1 }

// main's MyMaterial parameter.
dcl_interface fp0[1][1] = { ft0, ft1 };

// main shader code

// call AmbientLight or DirectionalLight based on function pointer bound
fcall fp0[0][0]

This patchset adds only dcl_function_body and dcl_function_table. Interfaces are going to be in a separate patch.

tagolog · 2026-05-28T04:19:30Z

+  let description = [{
+
+    The `dxsa.dcl_function_body` declares a unique function body #
+    whose code will appear later in the program at `label fb#`.


Maybe remove references to "fb#" syntax as we are not using it in the mlir for now?

tagolog · 2026-05-28T04:34:40Z

+
+// CHECK-LABEL: module
+
+// dcl_function_body fb1


Maybe it is worth no to mix the ops from prev asm with the current MLIR ops? This can be a bit misleading.

Agree. Removed.

asavonic · 2026-05-28T15:15:17Z

Also changed syntax a bit to spell out what the array means:

dxsa.dcl_function_table 0, <functions = [0, 1]>

tagolog · 2026-05-29T05:12:46Z

-  let arguments = (ins F32Attr:$max_tessfactor);
-  let assemblyFormat = "$max_tessfactor attr-dict";
-  let hasVerifier = 1;
+  let arguments = (ins I32Attr:$index);


This argument is positive by design, I vote to restrict it.

Suggested change

let arguments = (ins I32Attr:$index);

let arguments = (ins ConfinedAttr<I32Attr, [IntNonNegative]>:$index);

Thank you. Added restriction.

tagolog · 2026-05-29T05:13:53Z

-  let assemblyFormat =
-      "$operand `,` $struct_byte_stride `,` $struct_count attr-dict";
-  let hasVerifier = 1;
+  let arguments = (ins I32Attr:$index, DenseI32ArrayAttr:$functions);


Suggested change

let arguments = (ins I32Attr:$index, DenseI32ArrayAttr:$functions);

let arguments = (ins ConfinedAttr<I32Attr, [IntNonNegative]>:$index, DenseI32ArrayAttr:$functions);

tagolog · 2026-05-29T05:30:15Z

-    return builder.buildDclHsJoinPhaseInstanceCount(*count, loc);
-  }
+  FailureOr<Instruction> parseDclFunctionTable(Location loc) {
+    auto index = parseToken();


Extended length bit [31] for dcl_function_table is unhandled

The spec says the regular 7-bit length field can overflow, in which case bit [31] is set and the real length lives in the next DWORD:

d3d12TokenizedProgramFormat.hpp#L2486-L2490

// [30:24] Instruction length in DWORDs including the opcode token. // [31] 0 normally. 1 if extended operand definition, meaning next DWORD // contains extended operand description. If it is extended, then // it contains the actual instruction length in DWORDs, since // it may not fit into 7 bits if enough functions are defined.

DirectXShaderCompiler handles this explicitly ShaderBinary.cpp#L548-L558

Right now the parser ignores extended length bit for these opcodes and silently parses the next DWORD as function table identifier.

Good catch! Added handling of extended length token.

asavonic requested a review from tagolog May 22, 2026 15:31