All extractvalues of the same value at the same index will map to the same register, so even if one specific extractvalue only has one use, we should not mark it as a trivial kill, as there may be more extractvalues later.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This seems like a reasonable fix, whatever value my review of fastisel code has.
This issue seems likely to show up for other instructions in the future, as well. Some that come to mind as likely to trigger this same bug are: gep, freeze, phi, select, extractelement (not currently supported by fastisel),
I don't know this well, so a couple of drive-by comments inline.
@craig.topper or @RKSimon should have a look.
llvm/lib/CodeGen/SelectionDAG/FastISel.cpp | ||
---|---|---|
241 | The header comment for this function only says: /// Test whether the given value has exactly one use. That should be updated with a little more detail about the logic and usage. | |
llvm/test/CodeGen/X86/pr49467.ll | ||
3 | Does it make sense to specify the point-of-failure in the RUN line more explicitly with something like: -fast-isel -optimize-regalloc=0 |
llvm/lib/CodeGen/SelectionDAG/FastISel.cpp | ||
---|---|---|
241 | I expanded the comment a bit -- hopefully it makes sense, as I'm also not familiar with this code. | |
llvm/test/CodeGen/X86/pr49467.ll | ||
3 | I've added the -fast-isel flag, but don't think that -optimize-regalloc=0 is really relevant here, in that the problem manifests before that and is caught by -verify-machineinstrs (although FastRA would also assert). |
llvm/lib/CodeGen/SelectionDAG/FastISel.cpp | ||
---|---|---|
273–274 | Should this list of exception opcodes just be hoisted up to its own if+"return false" with a more directed comment? It's not important that we check I->hasOneUse() before them is it? |
This patch is intended as a minimal fix for LLVM 12. For the main branch, I think we should rip out the whole kill tracking in FastISel entirely. FastRA can determine kills itself, and at least in my test, there is no negative compile-time impact to letting it do so. Maybe this used to be different, but currently the hasTrivialKill functionality seems to be unnecessary complexity.
The header comment for this function only says:
That should be updated with a little more detail about the logic and usage.