Change BasicBlock::removePredecessor to optionally return a vector of
instructions which might be dead. Use this in ConstantFoldTerminator to
delete them if they are dead.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Utils/Local.cpp | ||
---|---|---|
135 | It seems unfortunate that we need to copy the vector. Do we believe there is another use case for MaybeDeadInstrs so we want it to take a Instruction vector? |
Like this? I had to include ValueHandle.h from BasicBlock.h. I don't know if that's acceptable.
This looks very reasonable to me.
llvm/lib/IR/BasicBlock.cpp | ||
---|---|---|
346–348 | Nitpick: I think it's better to put braces around multi-line if-guarded statements. |
llvm/lib/Transforms/Utils/Local.cpp | ||
---|---|---|
476–477 | removePredecessor only adds Instructions, but then in some cases it will replaceAllUsesWith one of those Instructions with an arbitrary Value. |
llvm/lib/Transforms/Utils/Local.cpp | ||
---|---|---|
132 | IIUC this function only deletes dead values if DeleteDeadConditions is true. Might be good to guard the new simplifications in a similar fashion. | |
476–477 | Hm, it seems a bit unfortunate that we would add instructions that we immediately RAUW afterwards. IIUC the only case where this would happen is where the incoming value for the removed predecessor is the original PN itself. Couldn't we simply not add the incoming instruction to DeadInsts? That seems like a cleaner solution and should be straight-forward. |
llvm/lib/Transforms/Utils/Local.cpp | ||
---|---|---|
132 | Under the same flag or a different one? In any case my preference would be not to do this unless/until we really need it. | |
476–477 |
No, I think the problem occurs when we first visit PHI node A, one of whose inputs is PHI node B, which we add to MaybeDeadInstrs; and then we visit PHI node B and find that it hasConstantValue. |
llvm/lib/Transforms/Utils/Local.cpp | ||
---|---|---|
132 | It would probably make sense to use the same flag. I assume there is a reason for making removing instructions conditional on an option (which defaults to false and some users set it to false). It seems like silently changing it to delete some other bits could trip over some existing users in obscure edge cases. It might be that none of the users actually care of course. But in that case we should remove the flag altogether. In any case, I think the behavior should be documented. | |
476–477 | Yeah that's another case, probably also possible to detect up-front. Anyways, it seems like we already allow non-instructions in DeadInsts in RecursivelyDeleteTriviallyDeadInstructions as well. Seems a bit odd to have something called DeadInsts containing non-instructions, but I guess that ship has sailed. Nevermind. |
Hi!
I wrote
https://bugs.llvm.org/show_bug.cgi?id=46343
about a crash that starts happening with this patch.
I will. For the time being I reverted this commit in rG6fdd5a28b7840185d1f75d5702e7e2f3c4723b1c.
Nitpick: I think it's better to put braces around multi-line if-guarded statements.