llvm dev - Oct 2007 - [LLVMdev] Supporting pre-allocated registers in LLVM

>> You mean a temporary defined in an instruction. OK, that is what i
>> basically
>> need here. Is it guaranteed to "live" in the physical
register for
>> the entire
>> program (or at least for a single function, which would trivially
>> work for
>> single-function programs)?
>No it's just guaranteed to be defined in a fixed register. The
>allocator is free to copy it to another register, spill it to stack.
>It all depends on proximity of uses and overall register pressure.
>
>Evan
I'm afraid you are right, based on what i'm reading from the Register
Allocation
section in the manuals. What i had in mind was that this would be possible: to
associate a temporary to a hard register for its entire lifetime, disabling
spills and coalescing. Of course, in extreme cases where a coloring cannot be
accomplished, the allocator would report the allocation as infeasible and stop.
It could be provided as user option; it makes sense for embedded systems with
asymmetrical storage resources (some of the registers are distributed and some
are placed in usual register files).

Could this be done in a more LLVM-friendly way? Is there any port defining
strange registers (like an accumulator or the HI,LO registers of a
MIPS-compatible)?

Nikolaos Kavvadias

On Oct 6, 2007, at 6:11 PM, nkavv at physics.auth.gr wrote:
>>> You mean a temporary defined in an instruction. OK, that is what i
>>> basically
>>> need here. Is it guaranteed to "live" in the physical
register for
>>> the entire
>>> program (or at least for a single function, which would trivially
>>> work for
>>> single-function programs)?
>
>> No it's just guaranteed to be defined in a fixed register. The
>> allocator is free to copy it to another register, spill it to stack.
>> It all depends on proximity of uses and overall register pressure.
>>
>> Evan
>
> I'm afraid you are right, based on what i'm reading from the  
> Register Allocation
> section in the manuals. What i had in mind was that this would be  
> possible: to
> associate a temporary to a hard register for its entire lifetime,  
> disabling
> spills and coalescing. Of course, in extreme cases where a coloring  
> cannot be
> accomplished, the allocator would report the allocation as  
> infeasible and stop.
> It could be provided as user option; it makes sense for embedded  
> systems with
> asymmetrical storage resources (some of the registers are  
> distributed and some
> are placed in usual register files).
>
You are thinking about the gcc extension which allows the programer  
to tie a register to global variable? This feature isn't implemented  
nor am I aware of anyone driving to get it to implemented. Looks like  
you will have to roll up your sleeves if that's what you want. :-)

Evan
> Could this be done in a more LLVM-friendly way? Is there any port  
> defining
> strange registers (like an accumulator or the HI,LO registers of a
> MIPS-compatible)?
>
> Nikolaos Kavvadias
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

>
> You are thinking about the gcc extension which allows the programer
> to tie a register to global variable? This feature isn't implemented
> nor am I aware of anyone driving to get it to implemented. Looks like
> you will have to roll up your sleeves if that's what you want. :-)
>
> Evan
Hi Evan

is this the -fixed-reg<num> feature, or something that has been introduced
lately (in gcc4)?

This feature would be useful, with minimal changes to the application source
code and could achieve the behavior i want for binding the global variable to
the register. I could live with this feature, and not something more complex,
i.e. associating temporaries to hard registers (pre-coloring) right after
instruction selection via a pass.


Nikolaos Kavvadias