[llvm-commits] [PATCH] Enable use of SPARC g2-g4 global registers

[Martin Whitaker]

Jakob Stoklund Olesen wrote:
>
> On Jul 11, 2011, at 12:24 PM, Martin Whitaker wrote:
>
>> This patch adds a SPARC code generator feature that allows the code generator to optionally use the global registers that are reserved for application use by the SPARC ABI (g2,g3,g4).
>>
>> It also changes the preferred register allocation order to give preference to the global and input registers, to increase the chances of being able to eliminate the frame save/restore in leaf functions (when that optimisation is added). I'm doing this now because it also makes the regression test for this patch simpler (and less likely to break in the future).
>>
>> Please review.
>
> There register stuff looks good to me, but someone who is familiar with SPARC should comment.
>
> +define void @test(i32* %ptr) nounwind {
> +entry:
> +; CHECK_N: ld [%i0], %i3
> +; CHECK_N: ld [%i0], %i2
> +; CHECK_N: ld [%i0], %i1
> +; CHECK_Y: ld [%i0], %g4
> +; CHECK_Y: ld [%i0], %g3
> +; CHECK_Y: ld [%i0], %g2
>
> Please don't write tests that depend on the exact details of register allocation. There is no reason these registers would be allocated in exactly that order.
>
This test is checking whether the feature of enabling/disabling use of the 
global registers g2-g4 is working. I spent some time thinking about this, but 
can't think of a way to test this that doesn't depend on the exact details of 
register allocation.

Just had a thought - is it possible to use regular expressions in the patterns 
to be matched?

> Check for the absence or presence of frame save/restore code instead.
>
That optimisation is not yet performed - it will (I hope) be the subject of a 
future patch. I changed the preferred register allocation order now to 
minimise the chances of the regression test associated with this patch 
breaking when that optimisation is added.

Martin