[LLVMdev] Casting between address spaces and address space semantics

[Gordon Henriksen]

On 2008-07-21, at 14:42, Matthijs Kooijman wrote:

> Hi Mon Ping,
>
>> As you also mentioned, I don't like that we pass a reference to  
>> TargetData with the AddrspacesDescriptor and that we have a static  
>> default implementation store in the class.  It is unclear to me if  
>> this is the right class for it as not as it describes the structure  
>> and alignment while address spaces seems distinct from that.  I  
>> feel that this information should be part of the TargetMachine as  
>> the address spaces description is part of a target machine but I  
>> may be wrong here so if someone has a different opinion here,  
>> please chime in.
> From the looks of it, TargetMachine was only used in the  
> codegenerator, and the other transformation passes can't access it.  
> Or is that a wrong observation on my side?
>
> Anyway, since this information is needed pretty much over the entire  
> field (ie, even clang should have it to know whether an implicit  
> should be generated or cause an error), TargetMachine might be way  
> too low level. TargetData seems okay, but might need a bit of a  
> redesign.
>
> Perhaps some way of coding these relations into the LLVM IR would be  
> needed as well? Or perhaps we could load the right set of relations  
> based on the target triple?
>
>> In terms of text based or not, I don't have a strong opinion.  I  
>> don't see a problem with a text based format as these relationships  
>> are pretty simple since there can't be weird overlaps.  With only  
>> the choice of disjoint, subset, and equivalent, the description  
>> shouldn't be too long and the tool can compute the transitive  
>> closure of the description and generate a reasonable efficient  
>> table for lookup.
> Hmm, you have a good point there. Transitivity should greatly limit  
> the number of possible options.
>
>> I  don't see a problem with defining one's own class to store this  
>> information either.
> Let's see about this later on then :-)
>
>> As an aside, I think that the default relationship for two  
>> different address spaces should be disjoint.  We should not  
>> encourage people to define equivalent address spaces as in general,  
>> I don't see why  someone would want to do that except in rare  
>> circumstances.
> Yeah, that made more sense to me as well. However, I set it to  
> Equivalent for now, to be compatible with what clang generates. If  
> we make clang listen to this code as well, changing the default to  
> Disjoint makes a lot of sense.
>
> So, can anyone shed some light on the TargetData/Machine/Whatever  
> issue?

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.

You probably want to somehow extend TargetData to encode the address  
space descriptions, including pointer sizes and address space  
relationships.

— Gordon