[LLVMdev] C embedded extensions and LLVM
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...
More information about the llvm-dev