[LLVMdev] (no subject)

Villmow, Micah Micah.Villmow at amd.com
Fri Jul 1 12:16:22 PDT 2011


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?

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.

Thanks,
Micah

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110701/702ffcda/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: output.txt
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110701/702ffcda/attachment.txt>


More information about the llvm-dev mailing list