Krzysztof Parzyszek
2013-Jan-14 21:39 UTC
[LLVMdev] Splitting live ranges of half-defined registers
On 1/14/2013 3:16 PM, Jakob Stoklund Olesen wrote:> > On Jan 14, 2013, at 12:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >> >> My question is: is this something that was a part of the design? > > Yes, the register allocator only deals in full-width virtual registers, so any copies or spills created will operate on the full register.I see. Unfortunately, this is causing some customer code to fail in compilation. The direct cause of the compilation failure is a complaint from the register scavenger in the scenario that I described in the first email. This is actually very much related to the other problem I've reported a while ago ("wrong value out of predecessor")---splitting (and spilling) of partially defined registers was also key to the failure occurring. I can deal with this locally, so it's not a major blocker for us. Thanks, -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Jakob Stoklund Olesen
2013-Jan-14 21:47 UTC
[LLVMdev] Splitting live ranges of half-defined registers
On Jan 14, 2013, at 1:39 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:> On 1/14/2013 3:16 PM, Jakob Stoklund Olesen wrote: >> >> On Jan 14, 2013, at 12:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >>> >>> My question is: is this something that was a part of the design? >> >> Yes, the register allocator only deals in full-width virtual registers, so any copies or spills created will operate on the full register. > > I see. > > Unfortunately, this is causing some customer code to fail in compilation. The direct cause of the compilation failure is a complaint from the register scavenger in the scenario that I described in the first email.It shouldn't be causing any compile time failures, the VirtRegRewriter is adding <imp-def> operands for the wide register to make it look like it is live everywhere the virtual register was live: vreg(64).low_half = vreg(32) // vreg(64) = 64-bit register Should be rewritten as: physreg(32) = other-physreg(32), physreg(64)<imp-def> In the worst case, you should get a 64-bit copy instruction where a 32-bit copy would have been sufficient. It is quite common for post-RA passes to get the <imp-def> operands wrong. It's really hard to get it right. The machine code verifier (llc -verify-machineinstrs) can find these errors. /jakob
Krzysztof Parzyszek
2013-Jan-14 22:09 UTC
[LLVMdev] Splitting live ranges of half-defined registers
On 1/14/2013 3:47 PM, Jakob Stoklund Olesen wrote:> > It shouldn't be causing any compile time failures, the VirtRegRewriter is adding <imp-def> operands for the wide register to make it look like it is live everywhere the virtual register was live: > > vreg(64).low_half = vreg(32) // vreg(64) = 64-bit register > > Should be rewritten as: > > physreg(32) = other-physreg(32), physreg(64)<imp-def> > > In the worst case, you should get a 64-bit copy instruction where a 32-bit copy would have been sufficient.As I mentioned off-mailing-list, for us this is often a lot worse than having a wider instruction. To give the context for the list audience---the problem is that if the 32-bit subregisters (which are actually independent registers) are used as a register pair, then in instructions in that live range, these 32-bit registers will be aliased to the super-register (the register pair). This, in turn, will cause false-dependencies between instructions that only access the (non-overlapping) 32-bit portions. For us, tracking of individual lanes would solve this issue, and I believe that it would lead to a better code quality in general. I am very interested in getting this effort going. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Seemingly Similar Threads
- [LLVMdev] Splitting live ranges of half-defined registers
- [LLVMdev] Splitting live ranges of half-defined registers
- [LLVMdev] Splitting live ranges of half-defined registers
- VirtRegMap invariant: no reserved physical registers?
- [LLVMdev] problem trying to write an LLVM register-allocation pass