[cfe-dev] "generic" address space

[Mon P Wang]

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.   I rather not specifying that the argument list is completely  
variable because I think that means that for any such a built-in, we  
would need to teach clang about that operation and signature.  I would  
prefer to teach clang that some intrinsics can take pointer to any  
address space but to a specific domain type and get that information  
from the signature of the intrinsics.  I would like to keep clang as  
clean as possible.  The only other possibility that I have though of   
other than loosing the parameter-argument constraint or the weird type  
is to generate a different built-in signature for the pointer type  
base on the address space of the use.  I didn't like that choice as it  
seemed dirty without much benefit.

   -- Mon Ping



On Jul 15, 2008, at 4:16 PM, Eli Friedman wrote:

> On Tue, Jul 15, 2008 at 8:50 AM, Mon P Wang <wangmp at apple.com> wrote:
>> Hi,
>> I took a look at what __buildin_shufflevector does.  In that case, it
>> enforces more rules than the type system allow after checking the  
>> call.  In
>> that vein, what I could do instead of using this weird type is
>> in ActOnCallExpr,when checking the arguments of an intrinsic call,  
>> instead
>> of calling
>>   CheckSingleAssignmentConstraints
>> I could call my own version, e.g.,  
>> CheckBuiltinAssignmentConstraints that
>> will allow mismatches between address spaces to go through.  How  
>> does that
>> sound?
>
> What we do for __builtin_shufflevector does is claim the argument list
> is completely variable, then check the actual arguments from
> CheckFunctionCall.  What I was thinking is that we could do the same
> thing for the builtins which can take alternate address spaces, i.e.
> __sync_*.  (Are there any other builtins for which you're planning
> address space overloading?)
>
> That said, your approach could also work, although it doesn't seem as
> clean to me.
>
> -Eli