[LLVMdev] C embedded extensions and LLVM

Chris Lattner sabre at nondot.org
Sun Nov 11 09:52:27 PST 2007

On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote:

> I've been playing around with clang/LLVM looking at adding partial  
> support for the draft technical report for embedded C extensions  
> (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ 
> n1169.pdf), specifically named address spaces.
> Named address spaces need to be tracked in LLVM in essentially all  
> the same places that alignment is tracked,

Others addressed the other questions, one (surprising?) thing I'd  

Unlike alignment and volatility, I think that the address space  
qualifier should be represented explicitly in the type system.  The  
reason for this is primarily that pointers to different address spaces  
are really very different sorts of beasties: for example they can be  
codegen'd to have different sizes.  Any property that affects how the  
value is stored in registers needs to be in the type instead of on the  
load/store instruction.  Also, unlike volatile, it is not common to  
cast a pointer between two different address spaces.

The good thing about this is that I think it will make it  
substantially easier to update the various llvm optimizations if you  
do this.  The meat of project boils down to adding a new address space  
qualifier field to PointerType, making sure PointerType takes this  
field into account when it is being uniqued, and adding the address  
space qualifier to things like global variable.

Does this sound reasonable?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071111/acf2aefa/attachment.html>

More information about the llvm-dev mailing list