Inlining of constants etc. in generated HLSL

I was inspecting the HLSL of my shader and I noticed that one line generated relatively a lot of code in the HLSL, which at first looks like unnecessary.

The line (in reshade shader lang)
The HLSL generated:Questions:
- Is there a reason why the constants aren't inlined?
- Why are there constants generated for swizzles, aren't these always the same? (so why generate them at this level and not at the global level?)
- The code uses more registers than needed. E.g. _137 is unneeded, as the value can be read directly into the variable 'coc', which is also how the original code is defined. Is this done because there's no analysis how a variable is used ? (i.e. at any cost the operation on the right hand side of an assignment is cached in a local variable to avoid having to re-do the operation later on again ? ).

Analysis of usage patterns is a pain so I don't blame you for not having analysis for this , was just interesting to see how 1 line of code results in multiple statements which seem unavoidable: when I rewrote the one line into code which uses float2's as var[0] etc., it resulted in same code or more, so there was little to do to optimize this to have much less statements.

I imagine the d3dcompiler will optimize a lot of this and therefore there's no need to do extra work here, but I don't know whether it indeed does this or not, hence my questions

Thanks in advance!

OtisInf wrote: - Is there a reason why the constants aren't inlined?

More complicated code. A constant is a SSA assignment like any other. Inlining them would require an additional step that keeps track of all the SSA IDs that are constants and print them directly instead of printing the SSA ID to the output. Surely possible, but not really worth the effort.

OtisInf wrote: - Why are there constants generated for swizzles, aren't these always the same? (so why generate them at this level and not at the global level?)

This is for compatibility with SPIR-V. It's more optimal to use a component lookup in SPIR-V compared to a swizzle (since there are no single-component swizzle instructions in SPIR-V). As such the compiler front-end converts single-component swizzles to component lookups. And the compiler backend (including the HLSL one) won't know that this was originally a swizzle.
The SPIR-V backend re-uses the same SSA ID for constants of the same value (since SPIR-V does not allow multiple constant definitions with the same value), but the HLSL backend doesn't since I didn't see it worth the effort. So it will just recreate a new constant every time.

OtisInf wrote: - The code uses more registers than needed. E.g. _137 is unneeded, as the value can be read directly into the variable 'coc', which is also how the original code is defined. Is this done because there's no analysis how a variable is used ? (i.e. at any cost the operation on the right hand side of an assignment is cached in a local variable to avoid having to re-do the operation later on again ? ).

The final code won't use more registers. The Microsoft HLSL compiler will resolve all these (as you suspected) and will generate the same code as if it was written inline. Note that the Microsoft compiler internally uses the very same representation (it converts to SSA too), so this should actually simplifies its work.

Thanks for the info! Agreed, the extra work doesn't seem worth it. Had totally forgotten about SSA's (It's been, what... 25 years or so since I last read the Dragon Book (Aoh Sethi Ullman ) and after reading up about them understand better now why you did it this way

One year later and this is actually implemented now (to reduce the size of the generated code and make it more readable).