This is an archive of the discontinued LLVM Phabricator instance.

Propagate debug info for Phi node in SSAUpdater
AbandonedPublic

Authored by samparker on Feb 6 2017, 2:12 AM.

Details

Reviewers
None
Summary

Phi nodes are created in the SSAUpdater, however debug info is not updated causing incorrect values after transformations like loop rotation. This patch inserts a new call to dbg.value for each variable operand of the phi that has debug metadata attached.

Diff Detail

Event Timeline

samparker created this revision.Feb 6 2017, 2:12 AM
davide added a subscriber: davide.Feb 6 2017, 7:21 AM
aprantl added inline comments.Feb 6 2017, 9:44 AM
test/Transforms/Util/phi-dbgvalue.ll
41

The "string" attributes can probably be stripped.

This change looks good to me, but I think it would be good if someone more experienced than me in the usage of debug metadata could give the final OK to this change.

samparker updated this revision to Diff 87620.Feb 8 2017, 2:15 AM

Removed the string attributes from the test case. Also moved the Update function into SSAUpdater instead of a static function of SSAUpdaterTraits because I wanted to call the function from within SSAUpdater as well.

Ping. Is there anyone who could take a look at this please?

As an example of the issue this is fixing:

int main(int a) {

for(int i = 1; i < 10; i++) {
  func2(i, i+a);
}

}
If we currently compile with clang, loop rotation will transform the debug information so that the value 'i' is always set to the constant 1 in the body of the loop.

Hi @dberlin
I see you're involved in debug, IR and SSA, so would you mind taking a look at this?

Thanks,
Sam

dberlin added inline comments.Feb 17 2017, 9:13 AM
lib/Transforms/Utils/SSAUpdater.cpp
218

This looks really badly n^2 per call.
Is there really no faster way?

samparker added inline comments.Feb 17 2017, 9:22 AM
lib/Transforms/Utils/SSAUpdater.cpp
218

I know it is going to be slow, but it was the only way I found... I have basically no experience in this area though and was hoping to get some suggestions.

Staring at this, so far i don't believe this is the correct way to fix this.

If you look at your before test case, there is a debug value for the phi.
for.cond: ; preds = %for.body, %entry

%i.0 = phi i32 [ 1, %entry ], [ %inc, %for.body ]
tail call void @llvm.dbg.value(metadata i32 %i.0, i64 0, metadata !13, metadata !11), !dbg !15

After, the dbg.value is destroyed as the phi is recreated in for.body:
for.body:
%i.01 = phi i32 [ 1, %entry ], [ %inc, %for.body ]

I agree that seems bad.

However, you are adding debug info based on operands of the phi, etc.
I don't see why the answer isn't "stash away debug value in loop rotate", "reattach to new phi name"?

Doing this in ssa updater seems .. strange, and the way you are doing it seems even stranger.
At worst, if you ere doing it in ssa updater, it should be something like "if the old phi result (*not* operand) had a use in debug info, the new one should".
But even then, this is something i would expect callers to deal with as they rewrite uses.

Hi Daniel,

Thanks for your comments. I had hoped that performing this in the SSA updater would prevent this bug from appearing in other passes that update/replace the Phi nodes. Do you think there's a way to achieve this in a manner that isn't local to loop rotate? And by stashing and replacing, will getMetadata and setMetadata be okay for this purpose? Would I still not have to update the debug value to reflect the value of the new phi node?

Thanks again,
sam

Hi Daniel,

Thanks for your comments. I had hoped that performing this in the SSA updater would prevent this bug from appearing in other passes that update/replace the Phi nodes.

I agree with your general idea and thought that it would be nice to solve once and for all.
However, if you wanted to do that, you'd have to do two things:
A. Demonstrate it was a general problem that needs solving (Ie there were other places with the same issue). This is just because we don't want to make a general thing to solve problems that may not actually be general.
B. Demonstrate you could do so quickly and efficiently in a general way. Especially in SSAUpdater, which gets used a *lot*.
If you want to do both, great.
So far, i think B is your bigger issue. Your approach so far is N^2, and it seems hard to make it not N^2 with the API SSAUpdater provides. I've got an SSAUpdater rewrite outstanding, but i didn't change the API.

If you demonstrate it's a larger problem, i'm happy to help think about what kind of API might allow us to solve this issue in better time bounds.
But such a thing may not be theoretically possible. In which case, i'd argue we should just bite the bullet and fix passes that have this issue, and do so in a way that is faster (and then add testcases to make sure nobody breaks it)

Do you think there's a way to achieve this in a manner that isn't local to loop rotate?

I'd need more data. IE at least some other examples where passes are breaking this

And by stashing and replacing, will getMetadata and setMetadata be okay for this purpose?

Sure

Would I still not have to update the debug value to reflect the value of the new phi node?

You would, but again, in the case of loop rotate, you know you have a 1:1 mapping between old and new.

Thanks again,
sam

Ok, well I will try to fix this in loop rotate for the moment. @keith.walker.arm , do we have any other debug issues that maybe related to this?

I currently don't know of any other optimisation phases where the debug information for the results of a phi node is incorrect; but I would not be surprised to find that once the loop rotate issue is fixed and the information is able to correctly propagate in this phase that other optimisation phases which copy phi nodes are also found to have a problem.

I've created a new patch to make the changes to LoopRotate: https://reviews.llvm.org/D30190

samparker abandoned this revision.Mar 7 2017, 10:00 AM