[LLVMdev] C embedded extensions and LLVM

[Chris Lattner]

On Nov 11, 2007, at 11:18 AM, Christopher Lamb wrote:
>> 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.

Right.

> Does supporting those casts require an explicit operation (ie  
> intrinsic)?

This should just be a bitcast from one pointer to another pointer type.

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

I don't know what the right answer is for codegen either.  I'd suggest  
getting the llvm ir self-consistent, then worrying about it.  Until we  
have a concrete machine that needs it, it is hard to anticipate what  
will be needed.  In an ideal world, we'll just need flags on load/ 
store nodes because the pointer registers will already be lowered to  
some other regclass.

-Chris