This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Fix the bug of machine sink
ClosedPublic

Authored by LuoYuanke on Jun 15 2022, 5:04 AM.

Details

Summary

The use operand may be undefined. In that case we can just continue to
check the next operand since it won't increase register pressure.

Diff Detail

Event Timeline

LuoYuanke created this revision.Jun 15 2022, 5:04 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 15 2022, 5:04 AM
LuoYuanke requested review of this revision.Jun 15 2022, 5:04 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 15 2022, 5:04 AM
shchenz accepted this revision.Jun 15 2022, 8:03 AM

LGTM with one nit. Thanks for fixing this.

llvm/lib/CodeGen/MachineSink.cpp
802

Maybe better to exclude the undef case at the very beginning?

This revision is now accepted and ready to land.Jun 15 2022, 8:03 AM
LuoYuanke added inline comments.Jun 15 2022, 8:14 AM
llvm/lib/CodeGen/MachineSink.cpp
802

So do we also ingore undef value for physical register?

Thanks @shchenz for review. Let me land this patch first and we can improve the code later.

Please choose a better title!

This revision was landed with ongoing or failed builds.Jun 15 2022, 8:47 AM
This revision was automatically updated to reflect the committed changes.

I'm also not sure right now if vregs without definitions are even legal MIR while we are still in MachineSSA... Checking that now

shchenz added inline comments.Jun 15 2022, 8:49 AM
llvm/lib/CodeGen/MachineSink.cpp
802

Do we have undef physical register? I don't see such usage and sounds weird to me, it is a physical register but it is undef....

I'm also not sure right now if vregs without definitions are even legal MIR while we are still in MachineSSA... Checking that now

Sorry, I merged it in a rush. We can revert it and add assert for nullptr if undef value is illegal in MIR.

MatzeB added inline comments.Jun 15 2022, 8:51 AM
llvm/lib/CodeGen/MachineSink.cpp
802

Yes the definition of a physical register may not be visible in the MIR (could be a parameter, a side effect of a call or exception unwinding etc...)

And physreg uses can be undef just like VRegs.

MatzeB added a comment.EditedJun 15 2022, 8:57 AM

I see this code in the MachineVerifier:

} else if (MRI->def_empty(Reg)) {
  report("Reading virtual register without a def", MO, MONum);

Which reads to me that we do not allow virtual registers without a definition if there is at least 1 read of the register. But I guess that means you can indeed have a vreg without a def if all the uses are marked undef or are debug operands or similar situations where MO.readsReg() is false.

I see this code in the MachineVerifier:

} else if (MRI->def_empty(Reg)) {
  report("Reading virtual register without a def", MO, MONum);

Which reads to me that we do not allow virtual registers without a definition if there is at least 1 read of the register. But I guess that means you can indeed have a vreg without a def if all the uses are marked undef or are debug operands or similar situations where MO.readsReg() is false.

We can add undef flag to tell verifier it is undef register, e.g., %2:gr32 = MOV32rr undef %3:gr32.

Yes that's what I wrote. It seems there is an exception that if for all operands you get readReg() == false (that includes undef) then it is indeed allowed to have a VReg without a definition.

I see this code in the MachineVerifier:

} else if (MRI->def_empty(Reg)) {
  report("Reading virtual register without a def", MO, MONum);

Which reads to me that we do not allow virtual registers without a definition if there is at least 1 read of the register. But I guess that means you can indeed have a vreg without a def if all the uses are marked undef or are debug operands or similar situations where MO.readsReg() is false.

We can add undef flag to tell verifier it is undef register, e.g., %2:gr32 = MOV32rr undef %3:gr32.