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/