[LLVMdev] PointerTypes with AddressSpace

[Chris Lattner]

On Sep 12, 2007, at 6:41 PM, <Alireza.Moshtaghi at microchip.com>  
<Alireza.Moshtaghi at microchip.com> wrote:

> Chris,
> Extending LLVM IR to support PointerTypes that take an address  
> space is
> what I was hoping to avoid. However, if we want to do things right,  
> that
> is probably the way to go. Now that we got here, let me write some  
> of my
> thoughts on this and solicit your input:

Okay, I agree that it's the right way to go.  Also, being able to  
eventually the Embedded C specification as Christopher points out  
seems very useful :).

> --- 1) Syntax extension:
> In our existing compiler for 8-bit microcontrollers, we have  
> introduced
> rom and ram qualifiers (with ram being the default one) that can be
> applied to any type for example:
> rom int a;        //integer in program memory
> rom int *a;       //ram pointer to integer in rom
> int * rom a;      //rom pointer to integer in ram
> rom int * rom a;  //rom pointer to integer in rom
> Is something similar to the above what you also envision?

As far as C syntax goes, I have no preference.  I think that  
following Embedded C makes the most sense.

> --- 2) Automatic pointers:
> This is what we don't have in our existing compiler, but many  
> people are
> asking for it. Would it be possible in LLVM to treat pointers as  
> general
> all the way to code generation, and then decide its Address Space  
> based
> on the following criteria? (we should be able to do so in an LLVM pass
> because at code generation time we have the full view of the program)
> -- a) Address Space of the pointer is the Address Space of the  
> variable 
> eg: ptr = &var; //AddSp of ptr becomes AddSp of var
> -- b) Address Space of the pointer is the address Space of the pointer
> eg: ptr1 = ptr2; //AddSp of ptr1 becomes AddSp of ptr2
> -- c) Conflicts inside functions are not resolvable and should  
> generate
> diagnostic.
> eg:
> void f(void){
>     generalPtr = romPtr;
>     //some code
>     generalPtr = ramPtr; // non resolvable conflict
> }

This basically amounts to type inference.  If you want this, it would  
have to be implemented in the front-end, not in at the LLVM level  
(you lose too much to give useful error reports etc).

Type inference is very nice, but it is not in the spirit of C at  
all.  C is very explicit (to a fault perhaps).

> -- d) Conflicts at the function interface will spawn a new function
> eg:
> void inc(int *a){
>     (*a)++;
> }
> void g(void){
>     inc(romPointer); // this will spawn an f with rom pointer
>     inc(ramPointer); // this will spawn an f with ram pointer
> }
>
> In the case of (2) we still need rom and ram qualifiers to declare
> variables in the intended Address Space, however the impact on the  
> front
> end will probably be reduced.
> A combination of (1) and (2) would probably be ideal.

This again is a front-end issue.  It sounds like you want generic  
functions ala C++ templates.  If you go down this path, you are  
basically designing your own c-like language, you're not doing a  
simple C extension (which is what Embedded C is).

Regardless of whether you choose to make your own language or use  
Embedded C, the LLVM support should be the same though.

-Chris