[LLVMdev] Casting between address spaces and address space semantics

[Chris Lattner]

On Jul 21, 2008, at 11:58 PM, Matthijs Kooijman wrote:

>>
>> You probably want to somehow extend TargetData to encode the address
>> space descriptions, including pointer sizes and address space
>> relationships.
> Hmm, you have an excellent point there, pointer sizes could indeed  
> easily have
> different sizes in different address spaces... That would make  
> TargetData
> indeed a logical place to put such info.

Yep, I think it makes sense for TargetData to have info about the size/ 
alignment of a pointer in each addr space.  That is also easy to encode.

> I'm not completely sure how a bitcast from one pointer type to  
> another would
> work then, it would probably need zext in addition to casting?

In the code generator, it can know a lot more information about what  
happens when bitcasting from one address space to another.  This  
doesn't have to go into TargetData.

> In this case, finding some text representation for the address space  
> relations
> make sense, so that these relations can be embedded into the LLVM IR  
> (possibly
> inside the "target datalayout" entry, or perhaps in a separate "target
> addrspaces" entry?

Are you envisioning an LLVM IR pass that mucks around with these?   
When would that be useful?

> This does makes you wonder what should happen when two modules with  
> different
> addrspace configurations are linked together. How is this currently  
> handled
> with datalayouts?

You can see this in Linker::LinkModules, basically one randomly  
overrides the other unless one modules is empty, in which case the non- 
empty one wins.

-Chris