[LLVMdev] Register allocation in two passes

[Jakob Stoklund Olesen]

On Dec 8, 2011, at 12:15 PM, Borja Ferrer wrote:

> Jakob I've just noticed that I'm getting false positives about spills when there are actually none.
> What is happening is that although execution reaches to the line spiller().spill(LRE); inside RAGreedy::selectOrSplit() the insertion of the spill is avoided because the register gets rematted. This is the debug output I'm getting to show what I mean:
> 
> Inline spilling DLDREGS:%vreg25,1.436782e-03 = [344r,640r:0)  0 at 344r
> From original %vreg8,1.838235e-03 = [224r,640r:0)  0 at 224r
> Value %vreg25:0 at 344r may remat from %vreg25<def> = LDIWRdK 2; DLDREGS:%vreg25
>     remat:  632r    %vreg28<def> = LDIWRdK 2; DLDREGS:%vreg28
>             640e    %R15R14<def> = COPY %vreg28<kill>; DLDREGS:%vreg28
>     interval: %vreg28,inf = [632r,640r:0)  0 at 632r
> All defs dead: %vreg25<def,dead> = LDIWRdK 2; DLDREGS:%vreg25
> Remat created 1 dead defs.
> Deleting dead def 344r    %vreg25<def,dead> = LDIWRdK 2; DLDREGS:%vreg25
> 0 registers to spill after remat. <----- NO SPILL
> 
> My question is how could I detect this behaviour so i don't get any false positives? I've thought of checking if the variable NewVRegs increases in size after the call to the spill() method meaning that a remat happened, but I don't know if this is always correct in all situation and another important thing, are there any more cases where a spill could be avoided getting more false positives?

The spiller will be calling into your target's storeRegToStackSlot hook when it actually inserts a spill. Make a note then.

/jakob