This is an archive of the discontinued LLVM Phabricator instance.

[TwoAddressInstruction] Fix handling of operands tied to early-clobbers
AbandonedPublic

Authored by foad on Nov 3 2021, 9:29 AM.

Details

Summary

When updating live intervals (with -early-live-intervals), fix handling
of live ranges that were previously tied to an early-clobber def but no
longer are.

Diff Detail

Event Timeline

foad created this revision.Nov 3 2021, 9:29 AM
foad requested review of this revision.Nov 3 2021, 9:29 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 3 2021, 9:30 AM
MatzeB added a comment.Nov 8 2021, 8:55 AM

I can't shake the feeling that we would be better of having the convertToThreeAddress callback fix the liveness information like it is doing with LV, rather than guessing around after the fact with repairIntervalsInRange... Not sure what the original intention here was and if its fair to ask for that big refactoring now...

llvm/lib/CodeGen/TwoAddressInstructionPass.cpp
708–718

You fix the early-clobber -> register case, but I guess register->early clobber could happen too, given that we don't really know what instruction is involved here.

MatzeB added inline comments.Nov 8 2021, 8:57 AM
llvm/test/CodeGen/RISCV/rvv/vwadd.w-rv64.ll
3

Could we create a separate .mir test instead?

foad added a comment.Nov 8 2021, 10:58 AM

I can't shake the feeling that we would be better of having the convertToThreeAddress callback fix the liveness information like it is doing with LV, rather than guessing around after the fact with repairIntervalsInRange... Not sure what the original intention here was and if its fair to ask for that big refactoring now...

I agree. I have fixed a few problems that I encountered in repairIntervalsInRange, but I am not sure if it will ever be 100% reliable.

I will try passing LIS into convertToThreeAddress instead.

foad added a comment.Nov 9 2021, 3:15 AM

I can't shake the feeling that we would be better of having the convertToThreeAddress callback fix the liveness information like it is doing with LV, rather than guessing around after the fact with repairIntervalsInRange... Not sure what the original intention here was and if its fair to ask for that big refactoring now...

I agree. I have fixed a few problems that I encountered in repairIntervalsInRange, but I am not sure if it will ever be 100% reliable.

Actually it is used more than I thought:

  • in MachineBasicBlock::SplitCriticalEdge
  • in PPCTLSDynamicCall::processBlock
  • after TargetInstrInfo::convertToThreeAddress
  • after TargetInstrInfo::unfoldMemoryOperand
  • in TwoAddressInstructionPass::eliminateRegSequence
foad abandoned this revision.Dec 9 2021, 6:43 AM

Superseded by D113493.