search for: d15667

...still be reordered with nearby instructions that *don’t* access that register. Dependencies still need to be tracked! I think copies could be optimized, but reserved registers are implicitly live out of the frame. Reserved register writes should not move across calls. See http://reviews.llvm.org/D15667. > == Motivation == > Generic backend code, especially register allocators make assumptions about how registers behave. These include things like the value in a register only changes in instruction with a def or regmask/clobber operand for that register or writing to the register changes its...

...with nearby instructions that *don’t* access that register. > > Dependencies still need to be tracked! > > I think copies could be optimized, but reserved registers are implicitly live out of the frame. Reserved register writes should not move across calls. See http://reviews.llvm.org/D15667. Indeed the current code respects ordering dependencies for reserved registers, so rule 3) above can just be removed and we treat reserved regsiters like any other for reordering. We can handle them like any other register for calls as well then I guess? Moving through calls should be legal if the...

Lately I have had a few discussions of what it means for a register to be unallocatable or reserved. As this comes up every now and again and I often struggled answering such questions I decided to write down some definite rules and codify the current usage and assumptions. I plan to put the rules below into the doxygen comments of MachineRegisterInfo etc. And I also hope that people will correct