[LLVMdev] overlay attribute

[Alireza.Moshtaghi at microchip.com]

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. 

But it concerns me when you say modifying alloca to global references
seems a more robust way of doing it. Could you elaborate on this? 

Thanks
A.

-----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