Also clean up a few places that were modifying code after register
allocation to set the renamable bit correctly to avoid failing this validation.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 14162 Build 14162: arc lint + arc unit
Event Timeline
lib/CodeGen/MachineVerifier.cpp | ||
---|---|---|
1111 | I know we already touched that in the other thread, but are we definitely giving up on all optimizations as soon as a MachineOperand has been assigned a reserved register? I guess we could say that given the liveness of reserved registers is not necessarily properly modeled, when such register is assigned to an operand, it won't be safe later on to change it, so that's expected. | |
lib/CodeGen/TargetInstrInfo.cpp | ||
182 | Looking at this snippet only, one could find it strange to have virtual registers not being renamable but when you look at the whole picture, we see these variables are not used for virtual registers thus we really don't care what we put here. Could you add a comment saying that this will be used only for PhysReg? |
lib/CodeGen/MachineVerifier.cpp | ||
---|---|---|
1111 | Yes, I agree with your answer to your question here :) |
I was contemplating whether we need a check that the register assigned on a renamable operand is a physreg. Of course we cannot even write a verifier for that as using MO::isRenamable() will immediately run into an assertion failure when that is not the case (which is good!).
I think the way to solve this would be to move the machine verifier logic around to a MachineOperand::verify() function. This would be nice in that it can access machine operand internals that way. On the other hand this would probably need a bunch of refactoring to make it play seamless with the machine verifier reporting infrastructure. So I don't expect this to be solved here (or by you), just writing my thoughts down.
LGTM, would be nice if you could split the fixes and the verifier changes into separate commits when pushing this.
I know we already touched that in the other thread, but are we definitely giving up on all optimizations as soon as a MachineOperand has been assigned a reserved register?
I guess we could say that given the liveness of reserved registers is not necessarily properly modeled, when such register is assigned to an operand, it won't be safe later on to change it, so that's expected.