diff options
| author | Philip Reames <listmail@philipreames.com> | 2021-05-19 09:50:21 -0700 |
|---|---|---|
| committer | Philip Reames <listmail@philipreames.com> | 2021-05-19 10:25:31 -0700 |
| commit | 449d14ebd23b80bbc8bb5a1ba7979b0e4092a2fc (patch) | |
| tree | 1cf85b3296542796ef3e22af420599bc19b61e7c /llvm/tools/llvm-mca/llvm-mca.cpp | |
| parent | 76b8754d1bba6a8490c0f7e8a9e2fb3d181f0b03 (diff) | |
| download | llvm-449d14ebd23b80bbc8bb5a1ba7979b0e4092a2fc.zip llvm-449d14ebd23b80bbc8bb5a1ba7979b0e4092a2fc.tar.gz llvm-449d14ebd23b80bbc8bb5a1ba7979b0e4092a2fc.tar.bz2 | |
Do actual DCE in LoopUnroll (try 4)
Turns out simplifyLoopIVs sometimes returns a non-dead instruction in it's DeadInsts out param. I had done a bit of NFC cleanup which was only NFC if simplifyLoopIVs obeyed it's documentation. I'm simplfy dropping that part of the change.
Commit message from try 3:
Recommitting after fixing a bug found post commit. Amusingly, try 1 had been correct, and by reverting to incorporate last minute review feedback, I introduce the bug. Oops. :)
Original commit message:
The problem was that recursively deleting an instruction can delete instructions beyond the current iterator (via a dead phi), thus invalidating iteration. Test case added in LoopUnroll/dce.ll to cover this case.
LoopUnroll does a limited DCE pass after unrolling, but if you have a chain of dead instructions, it only deletes the last one. Improve the code to recursively delete all trivially dead instructions.
Differential Revision: https://reviews.llvm.org/D102511
Diffstat (limited to 'llvm/tools/llvm-mca/llvm-mca.cpp')
0 files changed, 0 insertions, 0 deletions