This is an archive of the discontinued LLVM Phabricator instance.

[DSE] Ignore dbg value when instruction iterator is reset.
ClosedPublic

Authored by Henric on Jun 7 2016, 7:44 AM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

Henric updated this revision to Diff 59883.Jun 7 2016, 7:44 AM
Henric retitled this revision from to [DSE] Ignore dbg value when instruction iterator is reset..
Henric updated this object.
Henric added reviewers: probinson, JakeVanAdrighem.
Henric added a subscriber: llvm-commits.
Henric added a comment.Jun 7 2016, 8:10 AM

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.

aprantl edited edge metadata.Jun 13 2016, 2:59 PM

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 :)

silvas added a subscriber: silvas.Jun 13 2016, 4:29 PM

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.

Note: bb->eraseFromParent now returns an iterator, so you can fix this by returning and using that instead :)

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.

Seems like there are no real objections, so is it ok to push the fix?

dberlin accepted this revision.Jun 17 2016, 8:06 AM
dberlin added a reviewer: dberlin.
This revision is now accepted and ready to land.Jun 17 2016, 8:06 AM
Closed by commit rL273141: Fix for PR27940 (authored by patha). · Explain WhyJun 20 2016, 2:17 AM
This revision was automatically updated to reflect the committed changes.