Erase the call site info when deleting the calls during the tail duplication.
This will fix the issue found when committing the D73534.
Details
Diff Detail
Event Timeline
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. |
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! |
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?
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.
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.
Ditto, not sure why this isn't covered by the change in removeDeadBlock?