By LangRef, hoisting token-returning instructions obsures the origin
so it should be skipped. Found this issue while investigating a
CoroSplit pass crash.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
run update_test_checks.py on llvm/test/Transforms/LowerMatrixIntrinsics/transpose-opts.ll
Don't think we have a clear understanding of the transforms that are valid for token types, but this generally looks reasonable to me. We should avoid making token values flow across control flow edges, even if it does not require introducing a phi.
llvm/test/Transforms/LowerMatrixIntrinsics/transpose-opts.ll | ||
---|---|---|
975 ↗ | (On Diff #441817) | Unrelated change? Feel free to commit separately. |
llvm/test/Transforms/SimplifyCFG/hoist-skip-token.ll | ||
5 | Use update_test_checks please. | |
37 | It should be possible to simplify this test further, e.g. the outer loop structure doesn't really seem relevant here. |
llvm/lib/Transforms/Utils/SimplifyCFG.cpp | ||
---|---|---|
1477 | Ugh, I could have sworn I left a comment here, but apparently I didn't: This check shouldn't be here, it should be in the do/while loop below. Otherwise you'll only check that the first instruction doesn't return a token type, but may still hoist it if it's a later instruction. |
llvm/lib/Transforms/Utils/SimplifyCFG.cpp | ||
---|---|---|
1477 | Ah, thanks for the remainder. After giving it another thought, I'm curious if the check should be in isIdenticalToWhenDefined to say that any two token-returning instructions are distinct? WDYT? |
llvm/lib/Transforms/Utils/SimplifyCFG.cpp | ||
---|---|---|
1477 | I think isIdenticalToWhenDefined() is a too generic API for this check. I don't think there's anything generally wrong with merging token-returning calls -- the problem here is that we want to either hoist both the token-producing and token-consuming calls, or neither, and the simplest way to do that is to never hoist them. |
Address Nikita's feeback
llvm/lib/Transforms/Utils/SimplifyCFG.cpp | ||
---|---|---|
1477 | Agreed. Thanks. |
I think we need to clarify LangRef if this is illegal in general for tokens in general. If it is, we need to explain why. If it isn't, we need an attribute the express the right semantics here.
All LangRef really says at the moment is that a token can't be put behind a phi or select; it doesn't really describe if/when it's legal to merge instructions that produce tokens.
Yes. I also found the token type description could be more clear. I'll send a follow-up LangRef patch to clarify the intent.
Ugh, I could have sworn I left a comment here, but apparently I didn't: This check shouldn't be here, it should be in the do/while loop below. Otherwise you'll only check that the first instruction doesn't return a token type, but may still hoist it if it's a later instruction.