This feature is necessary for the ARMLoadStoreOpt cleanup that I will submit next.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Hi Matthias,
I miss something.
Why do we need to account for the pristine registers?
Thanks,
-Quentin
Before prologue/epilogue insertion we don't need to account for them. All current users for LivePhysRegs are before prologue/epilogue insertion so they won't need this (by default AddPristineRegs is false).
After prologue/epilogue insertion those registers are live, you cannot use them for temporary values or place an instruction that would clobber them. Now you can either include them in the set of live registers compute by this class, the alternative is that each time you ask LivePhysReg whether something is alive and you get a negative answer that it may be pristine registers and alive anyway. I decided that it less error prone to simply include the pristine registers in the live registers list.
Actually I just realized that the StackMapLiveness pass uses LivePhysRegs after prologue/epilogue insertion; At a first glance I'd say this is a bug and will miss the pristine registers (though I'm not sure what the repercussions are if pristine regs are missed in patchpoint instruction (or maybe someone adjust for that somewhere else in the code).
I agree, the error proneness is a good argument!
Small comments inlined.
Cheers,
-Quentin
lib/CodeGen/LivePhysRegs.cpp | ||
---|---|---|
140 ↗ | (On Diff #26821) | Is there a reason we are not using MachineFrameInfo::getPristineRegs? I may be wrong, but at first glance it seems as if we copied/pasted the code from there. |
lib/CodeGen/LivePhysRegs.cpp | ||
---|---|---|
140 ↗ | (On Diff #26821) | This is mostly because the existing API is clunky: getPristineRegs() returns a BitVector by value(!) and has to compute an additional intermediate bitvector which we can avoid here by clearing and setting the registers directly in the LivePhysRegs. |