[LLVMdev] C embedded extensions and LLVM

[Christopher Lamb]

On Nov 11, 2007, at 9:52 AM, Chris Lattner wrote:

>
> 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  
> recommend:
>
> 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.

Very true.

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

Though perhaps infrequent, casting between address spaces is allowed  
based on rules that the target defines indicating which address  
spaces are subsets of others. Does supporting those casts require an  
explicit operation (ie intrinsic)?

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

Bonus!

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

That sounds like it should be easier than adding the address space ID  
to all the instructions and SDNodes.

I'll give it a try and see what happens. I can see that adding it to  
the type system makes it easier on the optimizer, but I don't yet  
understand all the consequences for the code generator.

--
Christopher Lamb



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