[LLVMdev] overlay attribute

Chris Lattner sabre at nondot.org
Thu Apr 17 11:41:12 PDT 2008


On Wed, 16 Apr 2008 Alireza.Moshtaghi at microchip.com wrote:
> Chris,
> The reasons for not wanting the code generator to modify alloca to
> global references are:
> (1) Variable name is not as easily available in the code generator.
> (2) I did not want to go behind the back of compiler and change the
> storage class of a variable in the middle of the way. I felt more
> comfortable to have the frontend generate the correct information to
> begin with.

Ok, that is reasonable.  You could also run an llvm IR pass that converts 
one to the other, which sound fix #1 at least.  I agree that having the 
front-end emit the semantics that you want makes the most sense.

-Chris

> -----Original Message-----
> From: Chris Lattner [mailto:sabre at nondot.org]
> Sent: Tuesday, April 15, 2008 8:29 PM
> To: LLVM Developers Mailing List
> Cc: Alireza Moshtaghi - C13012
> Subject: Re: [LLVMdev] overlay attribute
>
>
> On Apr 10, 2008, at 10:44 AM, <Alireza.Moshtaghi at microchip.com>
> <Alireza.Moshtaghi at microchip.com
> > wrote:
>
>> I would like to make the following target specific modifications to
>> clang and would like to get some advice from experts.
>
> Ok.  cfe-dev might be more appropriate for clang questions, but...
>>
>> 1) My target supports very poor stack access so we implement "static
>> stack". In this model, all local variables will have static storage
>> class. I think I can take care of this in the
>> clang::CGDecl.cpp::CodeGenFunction::EmitBlockVarDecl()
>
> Is there any reason not to lower these to alloca, and then have the
> code generator turn alloca into references to globals?  That seems a
> more robust way to go.
>
>> 2) To improve memory usage, I also would like to add a new default
>> attribute "overlay" to local variables (all will have static storage
>> class as mentioned in 1). This attribute will be applied to all local
>> variables except if the user has explicitly made the variable static
>> in
>> which case the attribute is not added. I think I should be able to
>> take
>> care of this also in the same place
>> clang::CGDecl.cpp::CodeGenFunction::EmitBlockVarDecl() however I don't
>> know how to define and apply the "overlay" attribute.
>
> Ok.  I'm not sure what this does, but adding attributes is pretty
> easy, just look at some other examples.
>
>> 3) I did not find any way to access the attributes from llvm
>> backend. I
>> was wondering if I should use something similar to what address
>> space is
>> doing or there may be some other way possible.
>
> I'd strongly recommend using address spaces if possible.
>
>> 4) Input arguments and return value of all functions should also have
>> the same overlay-static storage class. I can take care of these
>> entirely
>> in the backend. However, I would like to know your feedback.
>
> I'm not sure what the question is :)
>
> -Chris
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/



More information about the llvm-dev mailing list