This is an archive of the discontinued LLVM Phabricator instance.

Peephole optimization causes different code generation at "-O2 -g" and "-O2".
ClosedPublic

Authored by kromanova on Feb 9 2014, 1:23 PM.

Details

Reviewers
echristo
Summary

Fix for BZ #18590: http://llvm.org/bugs/show_bug.cgi?id=18590

This code review is for the bug fix in peephole optimization that folds a load which defines one vreg into the one and only use of that vreg. With debug info, a DBG_VALUE that referenced the vreg considered to be a use, preventing the optimization.

The fix is to ignore DBG_VALUE's during the optimization, and undef a DBG_VALUE that references a vreg that gets removed.

The main issue is how to update the DBG_VALUE properly. I looked at all calls of isDebugValue() to see what is typically done. There is at least one case that does each of the following:

  • rewrite the debug info (this was during inlining to change the vreg)
  • delete it (happens in tail duplication)
  • undef's it, by setting register to %noreg (in eliminate dead insns)

Looking at those also showed that most optimization happily just skip any DBG_VALUE while iterating over insns. Which is what I do in this fix.

I also looked at all calls to MachineInstr::eraseFromParent() to see how other code dealt with DBG_VALUE's when deleting an instruction. In most cases it did nothing. Presumably because the live debug variable pass will clean it up. I tested a fix that does nothing to the DBG_VALUE for this peephole case and it does get set to %noreg by the live debug variable pass.

In the end this fix requires 3 simple changes:

  • skip DBG_VALUE's while iterating over instructions
  • only consider NonDBG uses when checking whether a def has a single use
  • undef any DBG_VALUE's that use the vreg getting folded.

Fix by Trevor Smigiel.

Diff Detail

Event Timeline

kromanova updated this revision to Unknown Object (????).Feb 13 2014, 12:13 AM
kromanova updated this revision to Unknown Object (????).Feb 13 2014, 3:36 PM

Accidentally removed a line from PeepholeOptimizer.cpp header. Restored it back.

echristo added inline comments.Feb 13 2014, 9:53 PM
lib/CodeGen/PeepholeOptimizer.cpp
598 ↗(On Diff #7097)

"effect" -> "affect"

641 ↗(On Diff #7097)

Elaborate here.

659 ↗(On Diff #7097)

I agree with Manman here on this - is there some more general way of doing this since we'll want to do it across multiple passes I imagine. It needs more comments for sure.

kromanova updated this revision to Unknown Object (????).Feb 27 2014, 8:10 PM

Attached is the updated patch that addresses the issues raised:

  • refactor the code that undefs DBG_VALUE into a function
    • the implementation is in MachineRegisterInfo
    • I could not see any other reasonably obvious place to add it
  • remove unnecessary debug info from test cases
  • improve comments

Hi Eric,
Does the new patch look good? Can I check in?
Thanks!
Katya.

echristo accepted this revision.Mar 5 2014, 9:33 PM

This looks fine. If the testcases from the other patch end up changing based on Chandler's review then go ahead and update these as well please?

You might want to verify that the code generation for your testcases doesn't change on an atom processor :)

Thanks!

-eric

Hi Eric,
Out of curiosity: what is so special about Atom? Are we talking about X86 or x86_64?

Just to confirm that we are on the same page...
You would like me to add one more check to the test. Something like that:
; RUN: llc < %s -mcpu=atom -mtriple=i686-linux | FileCheck %s

Should I do the same check (for Atom) for the other -g -O2/-O2 difference bug fix that I filed?
http://llvm-reviews.chandlerc.com/D2970

Thanks!
Katya.

kromanova updated this revision to Unknown Object (????).Mar 6 2014, 11:26 PM

Here is an updated patch.

  • it has been built and tested against trunk@203192 (Mar6)
  • the 2 test cases were merged to 1, and debug info reduced a bit more.
  • the test case was checked with -mcpu=atom

OK to commit?

LGTM. Thanks for all of the work, it's really appreciated.

Eugene.Zelenko closed this revision.Oct 3 2016, 6:27 PM
Eugene.Zelenko added a subscriber: Eugene.Zelenko.

Committed in rL203829.