This is an archive of the discontinued LLVM Phabricator instance.

[GVN] Set proper debug locations for some instructions created by GVN.
ClosedPublic

Authored by samsonov on Jun 9 2015, 5:15 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

samsonov updated this revision to Diff 27418.Jun 9 2015, 5:15 PM
samsonov retitled this revision from to [GVN] Set proper debug locations for some instructions created by GVN..
samsonov updated this object.
samsonov edited the test plan for this revision. (Show Details)
samsonov added reviewers: spatel, dblaikie.
samsonov added a subscriber: Unknown Object (MLST).

The GVN ones seem reasonable since the instructions they're replacing are deleted, are the ones in PHITransAddr the same?

-eric

The GVN ones seem reasonable since the instructions they're replacing are deleted, are the ones in PHITransAddr the same?

You could say so. Instructions created in PHITransAddr would eventually be used here:

// Okay, we can eliminate this load by inserting a reload in the predecessor
// and using PHI construction to get the value in the other predecessors, do
// it.
DEBUG(dbgs() << "GVN REMOVING PRE LOAD: " << *LI << '\n');
DEBUG(if (!NewInsts.empty())
        dbgs() << "INSERTED " << NewInsts.size() << " INSTS: "
               << *NewInsts.back() << '\n');

No, they aren't, and it will in fact, often get the wrong location for this.

But given how GVN works, and the expectation that it has that
phitransaddr will insert instructions for it,
this is pretty much the best you can do (unless you want to do nothing).

This is because PHITransAddr does not have any clue in the world about
what computation it is really going to eventually replace, and GVN
can't tell it, because GVN doesn't know either.

(Basically, GVN is asking phi translate "here's a load, translate all
of it's parts". PHI Translate doesn't just do phi translation, it will
in fact, go off looking to see if something might have the same
operands as the result, etc).

It will be "mostly" right for "depth 1" phi translation, however.

No, they aren't, and it will in fact, often get the wrong location for this.

But given how GVN works, and the expectation that it has that
phitransaddr will insert instructions for it,
this is pretty much the best you can do (unless you want to do nothing).

This is because PHITransAddr does not have any clue in the world about
what computation it is really going to eventually replace, and GVN
can't tell it, because GVN doesn't know either.

(Basically, GVN is asking phi translate "here's a load, translate all
of it's parts". PHI Translate doesn't just do phi translation, it will
in fact, go off looking to see if something might have the same
operands as the result, etc).

Right... But why is this wrong? Suppose GVN replaces a Load L in the basic block BB_3,
and the address computation for L involves values V1 from BB_1 (with location Loc_1) and V2 from BB_2 (with location Loc_2).

PHITransAddr basically just re-creates the address computation in some predecessor of BB_3.
Shouldn't instructions re-computing V1 and V2 be associated with the same locations Loc_1 and Loc_2 as the original values?

It will be "mostly" right for "depth 1" phi translation, however.

This revision was automatically updated to reflect the committed changes.