Narrow blanket SPIR-V legalization work in optimizer recipes

[AnastaZIuk]

Summary

• add SSARewriteMode
• add RegisterLegalizationPasses(bool preserve_interface, bool include_loop_unroll, SSARewriteMode ssa_rewrite_mode)
• make legalization-time SSA rewrite conditional on ssa_rewrite_mode
• make legalization-time full loop unroll conditional on include_loop_unroll
• keep the default performance recipe from always materializing LoopControl::Unroll
• narrow default performance SSA rewrite to SSARewriteMode::SpecialTypes
• replace the default performance recipe's global redundancy elimination with local redundancy elimination
• remove blanket multidimensional-array legalization from the generic legalization tail
• preserve legal OpImageTexelPointer image operands in LocalSingleStoreElim

Root cause

The current SPIR-V optimizer recipes still carry old blanket unroll decisions that inflate the module and then pay for expensive cleanup over that self-inflated IR.

LoopControl::Unroll as an IR hint is not the problem. The expensive part is treating that hint as a blanket request to immediately materialize full unroll in the generic optimizer path even when legality does not require it.

The same pattern existed in the generic SSA cleanup path. The hard legality constraints are narrow and concentrated around special cases such as opaque or resource-like objects, but the old recipe was still paying for broader cleanup over generic IR.

DXC can still provide targeted producer-side signals for the narrower correctness-sensitive cases in microsoft/DirectXShaderCompiler#8283.

The narrower recipe also exposed one existing image-atomic cleanup dependency. In that path local single-store elimination could rewrite through copied image values and leave OpImageTexelPointer with a non-pointer image operand. This branch now fixes that directly instead of restoring blanket cleanup.

Spec basis

The core SPIR-V specification is direct here:

Unroll — Performance hint. Strong request to unroll or unwind this loop.

DontUnroll — Performance hint. Strong request to keep this loop as a loop, without unrolling.

Spec:

• https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#Loop_Control

Khronos guidance on offline SPIR-V transforms is also direct:

general loop unwinding or unrolling

should be avoided in off-line transforms of SPIR-V meant to be portable across devices.

Such controls should be respected by target devices.

Whitepaper:

• https://registry.khronos.org/SPIR-V/papers/WhitePaper.pdf

The same spec split also matters for SSA cleanup. The hard legality rules are narrow:

Image, sampler, and sampled image objects must not appear as operands to OpPhi instructions, or OpSelect instructions, or any instructions other than the image or sampler instructions specified to operate on them.

All OpSampledImage instructions must be in the same block in which their Result <id> are consumed.

Spec:

• https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_universal_validation_rules

And core SPIR-V is explicit that generic storage-class reasoning does not automatically apply to intermediate SSA values:

Intermediate values do not form a storage class, and unless stated otherwise, storage class-based restrictions are not restrictions on intermediate objects and their types.

Spec:

• https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#Storage_Class

For the image-atomic follow-up, OpImageTexelPointer is also explicit:

Image must have a type of OpTypePointer with Type OpTypeImage.

Spec:

• https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpImageTexelPointer

Benchmark

• reproducer: godbolt.org/z/o5xf1hq36
• benchmark: 19.161 s -> 3.02282 s (median of 3 runs)

Validation

• fresh full local CodeGenSPIRV on the companion DXC branch passes with 1438 expected passes, 2 expected failures, and 0 unexpected failures

Companion DXC PR:
microsoft/DirectXShaderCompiler#8283

[CLAassistant]

All committers have signed the CLA.

[s-perron]

I have responded on the corresponding DXC pr: microsoft/DirectXShaderCompiler#8283 (review).

[devshgraphicsprogramming]

whats the purpose here?

[s-perron]

Inline enables many other optimizations. We do not implement inter-procedural-optimizations. If you are going to copy-propagate something written to in one function, and used in another function, the have to be inlined.

[devshgraphicsprogramming]

oh I just hacked a NBL_REF_ARG via expanding vk::ext_reference on regular function inout parameters, so we have less copies, but yes makes sense.