Description
In a couple ways, vectors marked precise directly or indirectly are not treated as native vectors in 6.9.
- The dx.attribute.precise() temporary function isn't generated with a native vector overload and instead extracts each scalar element and calls on them individually
- More impactfully, when dxil-cond-mem2reg tries to scalarize the precise vectors because it needs to keep them as allocas a little longer to retain their precise indications, if a single element is operated on, there will be a GEP instruction that the code doesn't expect
Steps to Reproduce
Create a local or output vector with the precise qualifier and perform an operation on a single element of it: https://godbolt.org/z/f96jebPW7
Actual Behavior
The first issue is invisible to the output, but viewing the code after dx.attribute.precise() is introduced by scalarrepl-param-hlsl or similar and before the call is eliminated, there are potentially a long list of extractions and scalar calls to the function that could impact compile performance for long vectors.
The second actually results in a crash since it triggers an llvm_unreachable when the GEP is encountered as it is neither a Load nor a Store
Environment
- DXC version 1.9.0.5280
- Host Operating System: MacOs/Windows
Description
In a couple ways, vectors marked
precisedirectly or indirectly are not treated as native vectors in 6.9.Steps to Reproduce
Create a local or output vector with the
precisequalifier and perform an operation on a single element of it: https://godbolt.org/z/f96jebPW7Actual Behavior
The first issue is invisible to the output, but viewing the code after dx.attribute.precise() is introduced by scalarrepl-param-hlsl or similar and before the call is eliminated, there are potentially a long list of extractions and scalar calls to the function that could impact compile performance for long vectors.
The second actually results in a crash since it triggers an llvm_unreachable when the GEP is encountered as it is neither a Load nor a Store
Environment