This is an archive of the discontinued LLVM Phabricator instance.

[CSInfo][TailDuplicator] Update the call site info
AbandonedPublic

Authored by djtodoro on Feb 14 2020, 7:27 AM.

Details

Reviewers
vsk
aprantl
dstenb
Summary

Erase the call site info when deleting the calls during the tail duplication.
This will fix the issue found when committing the D73534.

Diff Detail

Event Timeline

djtodoro created this revision.Feb 14 2020, 7:27 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 14 2020, 7:27 AM
vsk added inline comments.Feb 14 2020, 10:19 AM
llvm/lib/CodeGen/TailDuplicator.cpp
739

Ditto, not sure why this isn't covered by the change in removeDeadBlock?

867

Why is this change necessary? I think this part of tailDuplicate just duplicates the contents of TailBB into PredBB. The deletion doesn't look like it happens until we get back to tailDuplicateAndUpdate, in removeDeadBlock.

If anything I'd expect that we'd have to copyCallSiteInfo here. I'll dig into this some more, I easily might be missing something.

1037

This makes sense to me.

djtodoro marked an inline comment as done.Feb 14 2020, 10:34 AM
djtodoro added inline comments.
llvm/lib/CodeGen/TailDuplicator.cpp
867

I think this won’t get into the removeDeadBlock part in some situations for particular calls. Probably we should use move* or copy* method here... I was struggling with making a test case for this, and had not payed enough attention on this part. I’ll double check this as well. Thanks!

vsk added a comment.Feb 14 2020, 3:14 PM

FWIW, I applied this patch as well as D73534, then backed out the changes introduced here in duplicateSimpleBB and tailDuplicate, and got a clean check-llvm run (except for the test added here, which asserts that 'callSites' is empty). Did you notice some other test failing?

Note that we primarily use TailDuplicator::duplicateInstruction to copy instructions. That calls MachineFunction::CloneMachineInstr (via TargetInstrInfo::duplicate -> CloneMachineInstrBundle).

So perhaps we should just call MachineFunction::copyCallSiteInfo within CloneMachineInstr, if the original MI may have a call site entry?

vsk added a comment.Feb 14 2020, 3:35 PM

Btw if you're interested in tackling that, perhaps it'd be best to split things into multiple patches (so, land the removeDeadBlock change from this patch, enable entry values, then keep on iterating)?

So perhaps we should just call MachineFunction::copyCallSiteInfo within CloneMachineInstr, if the original MI may have a call site entry?

This sounds good to me, but I'll investigate that to see if we should call the eraseCallSiteInfo as well.

Btw if you're interested in tackling that, perhaps it'd be best to split things into multiple patches (so, land the removeDeadBlock change from this patch, enable entry values, then keep on iterating)?

Nice, I agree.

djtodoro planned changes to this revision.Feb 17 2020, 2:00 AM
djtodoro abandoned this revision.Feb 19 2020, 5:59 AM

No need for this one. After the investigation I am realizing the moveCallSiteInfo() was properly called within X86ExpandPseudo::ExpandMI(), and handled the situation from this test case.