-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[SPIR-V] sortBlocks()
can break validity of SPIR-V code by placing a block before its dominator
#110652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
fyi @Keenuts |
investigating this. |
…ranch/insertBranch functions (#110653) This PR fixes implementation of `SPIRVInstrInfo::analyzeBranch()` and adds implementations of `SPIRVInstrInfo::removeBranch()` and `SPIRVInstrInfo::insertBranch()` to support Branch Folding and If Conversion optimization. The attached test case failed before this PR due to report_fatal_error() firing on missing implementation of `SPIRVInstrInfo::removeBranch()`. The new test case is not able to pass spirv-val check at the moment due to the issue described in #110652 , this is not related to this PR. This PR also updates instructions definition in tablegen to set isBranch=1 for relevant instructions.
…ranch/insertBranch functions (llvm#110653) This PR fixes implementation of `SPIRVInstrInfo::analyzeBranch()` and adds implementations of `SPIRVInstrInfo::removeBranch()` and `SPIRVInstrInfo::insertBranch()` to support Branch Folding and If Conversion optimization. The attached test case failed before this PR due to report_fatal_error() firing on missing implementation of `SPIRVInstrInfo::removeBranch()`. The new test case is not able to pass spirv-val check at the moment due to the issue described in llvm#110652 , this is not related to this PR. This PR also updates instructions definition in tablegen to set isBranch=1 for relevant instructions.
This BB ordering issue has been fixed through #111026, but this code has another issue: PHI nodes & some type/decoration ordering. |
In SPIR-V, OpDecorate instructions are allowed to forward-declare a virtual register. But while we are at the MIR level, we must comply with stricter rules, meaning OpDecorate should be emited after, not before the reg definition. (In some cases, we defined those just before, switching to just after). Related to llvm#110652 Signed-off-by: Nathan Gauër <[email protected]>
In SPIR-V, OpDecorate instructions are allowed to forward-declare a virtual register. But while we are at the MIR level, we must comply with stricter rules, meaning OpDecorate should be emited after, not before the reg definition. (In some cases, we defined those just before, switching to just after). Related to llvm#110652 Signed-off-by: Nathan Gauër <[email protected]>
In SPIR-V, OpDecorate instructions are allowed to forward-declare a virtual register. But while we are at the MIR level, we must comply with stricter rules, meaning OpDecorate should be emited after, not before the reg definition. (In some cases, we defined those just before, switching to just after). Related to #110652 --------- Signed-off-by: Nathan Gauër <[email protected]>
In SPIR-V, OpDecorate instructions are allowed to forward-declare a virtual register. But while we are at the MIR level, we must comply with stricter rules, meaning OpDecorate should be emited after, not before the reg definition. (In some cases, we defined those just before, switching to just after). Related to llvm#110652 --------- Signed-off-by: Nathan Gauër <[email protected]>
This issue is now fixed in the main branch, and MIR verification passes. |
https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_universal_validation_rules has a rule that "The order of blocks in a function must satisfy the rule that blocks appear before all blocks they dominate.". It seems that
sortBlocks()
that is called fromSPIRVPrepareFunctions::runOnModule()
is able to break this requirement for the following reproducer:After validation we get
and the relevant fragment of the SPIRV code is
The text was updated successfully, but these errors were encountered: