[LLVMdev] allocating registers less "sparingly"

[Evan Cheng]

On Nov 6, 2007, at 9:09 AM, Christopher Lamb wrote:

>
>
> I'm only passingly familiar with the register allocator in LLVM, but  
> I'd think that you could tweak it's allocation policy to allocate  
> out of, say, sequential registers and only reuse registers with dead  
> values once it runs out of completely empty ones. Is this what you  
> want?

That will help. But it's not really a clean solution. A heuristic  
based solution is never going to achieve the kind of balanced usage  
that's desired.

On the other hand, repairing anti-dependencies is a well understood  
problem and if it's implemented will bring a lot more benefits (e.g.  
post allocation scheduling).

Evan

>
> --
> Christopher Lamb
>
>> I can understand that for many architectures without static  
>> scheduling etc.
>> the "allocate registers sparingly"-approach is the best one as it  
>> might lead
>> to less context data to be saved in calls, etc., but in our case  
>> the calls are
>> not usually the bottleneck as our target programs are at the moment  
>> mainly DSP
>> kernels and multimedia codecs which are usually loop-oriented. In  
>> addition,
>> LLVM seems to do an excellent job in inlining function calls.
>>
>> I look forward to your replies.
>>
>> The links:
>>
>> [1] http://en.wikipedia.org/wiki/Transport_triggered_architecture
>> [2] http://tce.cs.tut.fi/papers/TCE_Overview.pdf
>>
>> Best regards,
>> -- 
>> Pekka Jääskeläinen,
>> Researcher at Tampere Univ. of Technology, Finland.
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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