Narrow blanket SPIR-V loop unroll in optimizer recipes#2
Narrow blanket SPIR-V loop unroll in optimizer recipes#2AnastaZIuk wants to merge 2 commits intomainfrom
Conversation
|
Here's my $0.02, instead of wholesale deciding if we're going to unroll and what version of SSA rewrite we'll perform... We could track this in a bitfield per each a lot of this we can already infer from LoopControl and Function Control enums of the parent blocks and opcodes contained within, e.g. For example I would not want a legalization pass to inline a function so that a loop can be unrolled because the invariant is a function parameter. It could be that an additional decoration is needed for switches, other conditionals (aside from OpSelectionMerge control) and functions to control whether legalization should be attempted or not. 97% of the codegen shouldn't be made to pay for the 3% that needs full inlining, unroll, optimization and constant propagation to become legal. |
|
I haven't read the code that closely but it seems like Then the battle would be for Legalization passes without performance passes (so O0 instead of O3 in DXC) for debug builds of shaders to not do loop unrolls on Loop Control And Similar behavour w.r.t |
Summary
58kLoCRoot cause
The current SPIR-V optimizer recipes still carry two old blanket unroll decisions:
9fbcce4ca17dadded full loop unroll to legalization passes on 2018-09-193c47dac28208added full loop unroll to performance passes on 2020-05-20On a large preprocessed HLSL payload with many small
[unroll]loops this inflates the SPIR-V module far more than necessary and then pays for expensive cleanup over that self-inflated IR.LoopControl::Unrollas 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.A similar issue existed in the legalization tail. Some cleanup passes were effectively historical safety hammers rather than semantically required defaults. Narrowing them keeps the generic path correct while removing a large amount of unnecessary work.
DXC has the producer-side lowering context and knows when a specific HLSL pattern still requires materialized loop unroll or legalize-time SSA rewrite for correctness. The companion DXC patch in microsoft/DirectXShaderCompiler#8283 supplies that narrower signal, and its current branch head also materializes the companion SPIR-V submodule pointers.
Validation
58kLoCAMD Ryzen 5 5600G with Radeon Graphics,6physical cores,12logical processors, Windows-reported max clock3901 MHz19.161 sto6.042 s4.702 s2.464 sCodeGenSPIRVlit/FileCheck passes with the companion DXC branch:1403expected passes,2expected failures,0unexpectedCompanion DXC PR:
microsoft/DirectXShaderCompiler#8283