[LLVMdev] Embedded C Language Extensions

[Christopher Lamb]

My $0.02

On Sep 13, 2007, at 5:22 PM, <Alireza.Moshtaghi at microchip.com>  
<Alireza.Moshtaghi at microchip.com> wrote:

> Eg:
> --how many Address Spaces do we want to support in the LLVM IR
> --what address space names do we want to add to the front-end

I think that the name of the address spaces will need to be target  
specific, based on the target's front end. I'd guess that these would  
get mapped into a set of numbered address spaces that LLVM supports  
in the IR (and the target specific code generator). The number of  
address spaces that LLVM supports in the IR is mainly an encoding  
efficiency issue. I'd start with only a few (4 perhaps), as I believe  
that it should not be difficult to expand the number supported if a  
target appeared that needed them.

> --how best to model nested address spaces (if we want to support  
> this in
> IR)

Supporting nested address spaces is simply a matter of constraining  
transformations that may be applied. I think that this is mostly a  
front end issue (correct me if I'm wrong Chris), and if there are  
parts that need to be dealt with in LLVM they can be added after  
basic address space support is available.

> --do we want to provide some kind of support (type inference stuff)  
> for
> things like Automatic pointers that I mentioned earlier (in case some
> one wants to use them). I agree that this is against C language
> fundamentals, however, people are asking for them more and more and  
> some
> compilers are actually trying to support them in weird ways, I  
> think we
> can handle them in LLVM much better than how others do. But again,  
> this
> is probably at the bottom of our list anyways!

I think that this is something that can be tackled after the basic  
address space support is in place.

Here are some questions/suggestions that might help guide where to  
look through the code base and think about the design:
* Where does the address space information need to be stored in the IR?
	Globals, function parameters that are pointers, alloca's, malloc's,  
GEP's?
* What changes are required so that the address space info is  
preserved in the IR by existing passes?
* Where is the address space information consumed in the back end?
	My guess is instruction selection, which means that the DAG node  
form of LD/ST will need to carry address space information.
* What changes are required so that the address space info is  
preserved in the DAG nodes given existing transformations?

Perhaps take a look at how other pointer attributes (volatile/ 
noalias) weave their way through the data flow to get an idea of  
these further attributes might be handled.

Chris can most likely help answer those questions above and probably  
issues I haven't thought of as well =)

--
Christopher Lamb