[cfe-dev] "generic" address space

[Mon P Wang]

Hi,

I agree with you that AST should be as strongly typed as possible and  
be consistent.  (BTW, does clang handle K&R C and formal conversions  
when one doesn't see the prototype, i.e., the automatic promotion to  
double and then converting it back to float).  If we want to make it  
very clear on the AST, we could create a special operator that  
indicates that a address mismatch is allowed.  I'm not sure what to  
call it but it is more of an type adaptor than a conversion.  This  
would make it very clear at the AST what is going on without resorting  
to a weird placeholder type.  Another possibility is that we could tag  
the ParmVarDecl to indicate that this parameter can ignore any address  
space differences between the argument and the parameter.

   -- Mon Ping


On Jul 15, 2008, at 10:56 PM, Eli Friedman wrote:

> On Tue, Jul 15, 2008 at 10:28 PM, Mon P Wang <wangmp at apple.com> wrote:
>> 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.
>
> The issue is that the types of the function arguments won't match the
> type of the call, which would be surprising for most AST consumers.
>
>> 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?
>
> Mmmm, it looks like clang's versions of the __sync_* builtins are
> broken in that respect.  I think some custom logic is needed for the
> overloading.
>
>> 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.
>
> Hmm, okay... I'm trying to get a feel for what sorts of intrinsics for
> alternate address spaces we'll want, and for which ones it's useful to
> overload the address space of the pointer arguments.  For example, for
> the R600 ISA (which I skimmed), I can't think of any intrinsics for
> which overloading would be useful; it seems like the address spaces
> are implied by the instruction.  Do you have any examples where it
> would be useful to overload the address space of platform-specific
> intrinsics?
>
> -Eli

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