[LLVMdev] (no subject)

[Jakob Stoklund Olesen]

On Jul 1, 2011, at 12:16 PM, Villmow, Micah wrote:

> I'm trying to debug a problem with our custom backend with using a tiered register allocation setup.
>  
> Just a little background. My target uses vec4 32bit registers and I want to have three levels of registers setup.
> Each vec4 register can have two sub-regs of size vec2 32bit, and each sub-reg, has its own two sub-regs of 32bit each.
> So it looks like this, xyzw -> {xy, zw} -> {x, y, z, w}.
>  
> Now the problem I am having is that for some reason, the linearscan allocator is running out of registers to allocate.
>  
> This makes no sense to me as I have 1024 vec4 registers(so 2048 vec2 and 4096 scalars).
> So I limited to a very small test case where I have 1 vec4(2 vec2 and 4 scalar) registers with
> a function that requires 1 vec4 register and 5 scalar registers. So, basically what happens
> is that everything works fine until the live-in register(which is scalar) to the function
> conflicts with a register that is allocated for the vector(as it is a sub-sub-reg). The
> linear scan allocator attempts to spill the live-in onto itself and then asserts with
> assert(false && "Ran out of registers during register allocation!");.
>  
> I've attached the output of running LLC on my test case, which
> I don't know if it will be helpful or not, to see what the live
> interval and reg allocator are doing.
>  
> I'm having trouble debugging this, any idea on where I might want to look?

It's hard to tell without knowing your target. Why does the allocator think there are no free registers in your register class?

> Another question is how do I influence the spill costs? I want to make live in's
>  
> infinitely expensive to spill, so any superreg or super-super-reg of the live in
> never gets allocated.

It's not clear what you mean here. Spill costs are assigned to virtual registers, and virtual registers don't have sub- or super-registers.

If you mean linear scan's emergency spilling of physical registers, that should never happen anyway. Something else is wrong.

BTW, the new greedy register allocator is way better. It never makes mistakes!

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110701/fbd8e12a/attachment.html>