Fix for PR27940
After a store has been eliminated, when making sure that the instruction
iterator points to a valid instruction, dbg intrinsics are now ignored as
a new instruction.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
An other approach is to set BBI = BB.begin() instead of stepping one instruction back. with --BBI.
What can happen is that when removing a dead store we might delete now dead loads as well. And in some cases this opens up for new DSE. (which is the case in the submitted test case) In the supplied test the new store is just before the initial target which triggers an other removal, but one can easily construct a case where we have other instructions in between.
So if we instead start from the beginning of the BB we might open up for more optimizations. But this of course changes the complexity of the function.
IIUC, this is fixing a case where -g affects codegen, and does so without degrading debug info quality?
Note: bb->eraseFromParent now returns an iterator, so you can fix this by returning and using that instead :)
Sorry, this is sort of a side comment: what iterator does it return? I'm having a hard time seeing based on the docs.
This will change the behavior quite a bit, and then I think it's better to change it so we set BBI = BB.begin()
We typically have this case:
Store -> A (Dead)
nextInst (so iterator from eraseFromParent() will point here)
...
Store -> A (current instruction)
nextInst (BBI typically points here)
But this also made me realize that all this --BBI might also be unnecessary, just setting BBI to Inst->getIterator() might be good enough.
On the other hand if we also remove loads and not only the store instruction, then we might open up for detecting new dead stores, so could be worth it to revisiting the basic block from the beginning again.