[LLVMdev] addrspace attribute and intrisics

[Mon P Wang]

Hi,

I got pulled off doing other things last week but I plan to get the  
support for address spaces to the intrinsics this week. As Benedict  
noted, the problem is that we don't carry the address space  
information with the intrinsics.  Today, we will do an implicit cast  
to the default address space.  My change will prevent that from  
happening by allowing the intrinsic to have a signature with an  
address qualified pointer.   This will change the name of the  
intrinsics.  When I talked to Dan about this, we thought it made sense  
to add a pointer qualifier to the name.  For example, the name of the  
atomic add will change from @llvm.atomic.load.add.i32 to
    @llvm.atomic.load.add.p0i32     // i32 ptr to default address space
    @llvm.atomic.load.add.p11i32   // i32 ptr to address space 11

This means we will auto convert the old names to the new one.   I'm  
also planning to change clang to generate an error if the compiler  
implicitly cast a pointer between two different address spaces.  If  
anyone has an issue or concerns, please let me know.

   -- Mon Ping


On Jul 3, 2008, at 10:11 AM, Chris Lattner wrote:

> On Thu, 3 Jul 2008, Benedict Gaster wrote:
>> I am slightly unclear about the semantics of the addrspace  
>> attribute and there use with intrinsics. For example, is the  
>> following code valid:
>>
>> % ptr      = malloc i32 addrspace(11)
>> % result = call i32 @llvm.atomic.load.add.i32( i32 addrspace(11)*  
>> %ptr, i32 4);
>>
>> If this is valid it means that a certain amount of type information  
>> is lost at the LLVM IL level and if it is not valid, then it is  
>> impossible to use any of the built-in functions for anything other  
>> than the default address space.
>
> That is not currently supported, but Mon Ping is working on it (as I  
> understand).  Mon Ping, are you still working on this?  If so, what  
> is the status?
>
> -Chris
>
> -- 
> http://nondot.org/sabre/
> http://llvm.org/