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

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?

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/20080721/954ece73/attachment.sig>

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

Hi Matthijs,
>
>> 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?
At some level, I think we are hitting the design question about how  
can some transformation get access to target dependent information for  
a transformation phase.  As we get more phases, this might become more  
of an issue.   For example, assuming one wants to block (tile) a loop  
based on the cache size of the machine.  The loop transformation phase  
will need access to target dependent information. As you noted,  
TargetMachine is used by CodeGen as well as some utility like llc.   
Assuming TargetMachine is the right location for this information, I  
don't see a problem if a phase needs to get access to the object.

In terms of encoding this information in the LLVM IR, I rather not  
unless there is a real need.  The target we are compiling for should  
have this information.  If we start encoding the address spaces, do we  
also need to encode other information like stack layout etc?
> [deleted text]
>
>> 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.
>
I was going to change the default in clang to make implicit casting of  
between address spaces  illegal.  Having this information will  
supersede that change as we will have the correct information to do  
the right thing based on the target.

Best regards,
   -- Mon Ping

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080721/b4c00203/attachment.html>

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>