[LLVMdev] Casting between address spaces and address space semantics

[Matthijs Kooijman]

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>