[LLVMdev] Casting between address spaces and address space semantics

[Chris Lattner]

On Jul 22, 2008, at 1:36 AM, Matthijs Kooijman wrote:
>> 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?

Only if absolutely required, see below.

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

I think it should be safe for instcombine to assume there is no  
truncation of pointers.  If you have ptra -> ptrb -> ptra, it is  
theoretically possible that ptrb is smaller than ptra pointers.   
However, this is a form of pointer overflow, which llvm treats as  
undefined already.  Further, it isn't clear to me that this is going  
to be common enough for instcombine to really worry about.  Only  
handling it in the code generator seems fine to me, but maybe you have  
a different use case for addrspaces in mind.

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

Clang should just reject implicit casts in *any* case when the addr  
spaces differ IMO.  In any case, clang has it's own parameterization  
of the target which is richer than TargetData already, so if it really  
wanted to allow implicit casts between address space subsets, it could  
do so based on its own info.

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

What would the warning say?  There is nothing useful the linker could  
tell the user, and having a low level tool like the llvm linker  
library emit warnings (where? to stderr?) is extremely impolite for  
some clients.  If a specific client cares about this, it should check  
and report in its own way.

-Chris