[LLVMdev] Casting between address spaces and address space semantics

[Matthijs Kooijman]

Hi Gordon,

> TargetData is a concrete class, part of the middle-end. It describes  
> parts of the the target's ABI. It allows target-independent passes to  
> do things like decide whether x[1] and ((char *) x)[4] alias. This is  
> possible without actually linking with the code generator for the  
> relevant target. TargetData can be encoded in the LLVM IR, e.g. target  
> datalayout = "...........".
> 
> TargetMachine is an abstract factory class used to gain access to all  
> features of the code generator.
> 
> There is not a 1:1 mapping between TargetData and TargetMachine; Mac,  
> Linux, and Windows all have different data layouts, but use the same  
> X86 TargetMachine.
Ok, that makes sense.

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

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

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?

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080722/43806e0d/attachment.sig>