[cfe-dev] "generic" address space

[Mon P Wang]

Hi Eli,

Whatever we do, it should be clear when examining the AST that we are  
matching an address space overloaded intrinsic.  I'm not sure what new  
AST expression tree would make sense.  I view it that we have an call  
expression to an address space overloaded intrinsic function.  When we  
check the argument and parameter of the signature, the normal rules  
follow except for parameters that can accept different address space.   
During code generation, the different argument type will generate a  
slightly different intrinsic function like  
@llvm.atomic.load.add.i32.p0i32.

It is a bit unclear to me what happens with intrinsics that can take  
any integer width.  Looking briefily, it looks like clang will  
generate an implicit cast for the argument to integer.  Do we always  
generate the 32 bit integer version of these intrinsics?

Various DSPs (e.g TI TMS320C30), embedded architectures and GPUs  
support different address spaces. The Cell processor has local memory  
accessible only by the SPUs. Nvidia and AMD GPUs  typically have  
different address spaces for things like local or textures.  It is  
difficult to get their ISAs though AMD has released their R600 ISA (http://www.x.org/docs/AMD/r600isa.pdf 
).  I'll have to look to see what is available publicly.

-- Mon Ping

On Jul 15, 2008, at 6:42 PM, Eli Friedman wrote:

> On Tue, Jul 15, 2008 at 5:38 PM, Mon P Wang <wangmp at apple.com> wrote:
>> Hi Eli,
>>
>> On an architecture that support address spaces,  any builtins that  
>> touches
>> memory would probably need this support.  Today, I think it's  
>> mostly the
>> sync functions.  For a specific architecture, one is likely to add
>> architecture specific built-ins to support some other operations that
>> touches memory and I would like to use the same mechanism (e.g.,  
>> specialized
>> load/store instructions) to do the check.
>
> Ah, I see... I hadn't really considered the arch-specific builtins
> part.  In that case, adding some generic machinery might be
> appropriate.  That said, I've never actually seen an architecture with
> multiple address spaces, so pointers to any documentation would be
> helpful.
>
> I don't think we should be abusing existing machinery to handle this
> case; therefore, I think there should be a new kind of AST expression
> for address-space-overloaded intrinsics.  This makes it explicit that
> there is something unusual going on with the types for such intrinsic
> calls.
>
> -Eli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080715/4fc74c69/attachment.html>