search for: d14750

...tRegs are assumed to have a definition, physregs can appear "out of thin air" in some situations like function parameters, or exception objects appearing in a register when going to a landingpad. >>> >>> This is what Dan is trying to address with http://reviews.llvm.org/D14750 <http://reviews.llvm.org/D14750>. The discussion on that change is essentially the same as the one going on here. >>> >>> - VirtRegs are assumed to be interchangeable, replaceing vreg5 with vreg42 shouldn't affect the program semanic (given they both have the same regi...

...assumed to have a definition, physregs can appear "out of >> thin air" in some situations like function parameters, or exception objects >> appearing in a register when going to a landingpad. >> > > This is what Dan is trying to address with http://reviews.llvm.org/D14750. > The discussion on that change is essentially the same as the one going on > here. > > >> - VirtRegs are assumed to be interchangeable, replaceing vreg5 with >> vreg42 shouldn't affect the program semanic (given they both have the same >> register class and we ha...

...finition, physregs can appear "out of >>> thin air" in some situations like function parameters, or exception objects >>> appearing in a register when going to a landingpad. >>> >> >> This is what Dan is trying to address with http://reviews.llvm.org/D14750. >> The discussion on that change is essentially the same as the one going on >> here. >> >> >>> - VirtRegs are assumed to be interchangeable, replaceing vreg5 with >>> vreg42 shouldn't affect the program semanic (given they both have the same >>&...

To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way. Problems when using virtregs throughout the backend until emit time: - The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs - VirtRegs are assumed to have a definition,