[LLVMdev] Reserving registers that depend on spilled code

[Borja Ferrer]

Hello, does anybody know a way to solve this problem? I've seen that other
backends have the same issue, but they all solve it by reserving the
register unconditionally being this too over conservative. As explained in
my previous email this is not a valid solution because in my case since it
would degrade code quality in a big manner.

Thanks

2011/5/20 Borja Ferrer <borja.ferav at gmail.com>

> Hello,
>
> I would like to reserve a register or make it available to the register
> allocator depending if the stack is used inside a function or not. By using
> the stack i mean the following: if all regs are spilled so that frame space
> has to be allocated, arguments passed through the stack and allocas. I know
> how to get the last two options when the register allocator is run since
> that info is already available, but how can you know if all regs are going
> to be spilled? I can only think that to get this information you need to run
> the allocator to see if there are frame indices inserted because it ran out
> of regs and then re run it again reserving this specific reg so there are no
> conflicts during prolog/epilog insertion.
>
> The reserved reg is the one used to access the frame indices and the stack,
> so if it's allocated in a function that makes use of the stack then there's
> a going to be a conflict. Otherwise if it's always reserved, it's a very
> precious waste because this arch has only 2 regs that are able to access
> memory so if one is always reserved you can imagine that things get very
> suboptimal regarding memory accesses.
>
> I've thought something like running the allocator once, and if frame
> indices get inserted meaning that all regs got spilled, re run it reserving
> this specific reg, otherwise the allocation was valid and the reg can be
> used freely inside the function.
>
> Thanks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110525/e42e0dcb/attachment.html>