[LLVMdev] Casting between address spaces and address space semantics

[Matthijs Kooijman]

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>