Displaying 4 results from an estimated 4 matches for "low_half".
2013 Jan 14
2
[LLVMdev] Splitting live ranges of half-defined registers
...tten about something similar (either on the list, or
in private communication), so this may look familiar.
Here's a scenario I'm observing:
First, we have some innocent looking code:
vreg(32) = x // vreg(32) = 32-bit register
... = vreg(32)
[...]
vreg(64).low_half = vreg(32) // vreg(64) = 64-bit register
[...]
then, after register coalescing:
vreg(64).low_half = x
... = vreg(64).low_half
[...]
[etc.]
then, the live range of the 64-bit vreg is split during register allocation:
vreg'(64).low_half = x // first live range start...
2013 Jan 14
0
[LLVMdev] Splitting live ranges of half-defined registers
...ither on the list, or in private communication), so this may look familiar.
>
> Here's a scenario I'm observing:
>
> First, we have some innocent looking code:
> vreg(32) = x // vreg(32) = 32-bit register
> ... = vreg(32)
> [...]
> vreg(64).low_half = vreg(32) // vreg(64) = 64-bit register
> [...]
>
> then, after register coalescing:
> vreg(64).low_half = x
> ... = vreg(64).low_half
> [...]
> [etc.]
>
> then, the live range of the 64-bit vreg is split during register allocation:
> vreg'(64).low_...
2013 Jan 14
0
[LLVMdev] Splitting live ranges of half-defined registers
...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...
2013 Jan 14
2
[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.