[LLVMdev] Casting between address spaces and address space semantics

[Mon P Wang]

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>