llvm dev - Jul 2008 - [LLVMdev] Casting between address spaces and address space semantics

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>

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

Hi Chris,

> >> 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.
Which is an added bonus, but the original subject under discussion was the
relations between each address space (equivalent, disjoint, subset/superset).
Any thoughts on that? Should they also belong in TargetData?
> > 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.
Well, if the pointers really are differently sized, you couldn't just
bitcast
between them, since bitcast requires values of equal bitlength? Or is this
something that would only be exposed when doing intoptr/ptrtoint and simply
assumed to be handled in the backend for pointer-to-pointer bitcasts?
> > 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?
Not a particular pass, but passes in general. Specifically, I would like
instcombining to be able to use this info to remove useless bitcasts. Also,
this information is useful for clang to know when inserting an implicit cast
makes sense and when it would be an error.
> 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.
Shouldn't this give a warning instead of silently picking one? Also,
couldn't
this produces an invalid module? Say, for example that one module has 16 bit
pointers and the other 32 bit. If we use 32 bit as the resulting pointer size,
but the other module contained something like
	%int = ptrtoint i32* %A to i16

This could suddenly cause truncation of the pointer, where it didn't in the
original module. Warning for this seems appropriate? The same would go for
different address space configurations, I expect mixing those could cause
nasty, but probabl very subtle bugs...

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/abc5e128/attachment.sig>