[cfe-dev] "generic" address space

[Mon P Wang]

By a new expr tree, do you mean that instead of creating a CallExpr,  
we create another node type like IntrinsicExpr and these have slightly  
different rules for processing?  During CodeGen, both of these nodes  
will be process the same.  If that is the case, I don't see much of a  
problem going this way.

At the time when I first thought about synthesizing the prototype, my  
concern was that we will be spending some extra time to create the  
prototype and do some redundant work because after we create the  
prototype, we would check it again since we will pass it to normal  
processing.  However, we already to create the intrinsic on the fly  
and when we create a custom prototype based on some call site  
information, we could skip the regular checks and conversions since we  
would have already done this.  At the abstraction level, it does seem  
the cleanest way to go since arguments would match correctly.

  -- Mon Ping


On Jul 16, 2008, at 10:57 PM, Eli Friedman wrote:

> On Wed, Jul 16, 2008 at 10:34 PM, Mon P Wang <wangmp at apple.com> wrote
>> (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).
>
> clang should handle everything related to promotions and functions
> without prototypes correctly; please file a bug if you find any
> issues.
>
>> 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.
>
> All possibilities, I guess... I'm not particularly fond of any of
> them.  I still think adding a new type of AST expression instead of
> the call would be better.  These builtins aren't really functions at
> all, but overloaded function-style operators, and overloading the
> semantics with non-calls seems messy.
>
> I suppose another possibility (which I think you mentioned in passing)
> would be to synthesize decls for the various legal overloads on
> demand.  The synthesis step is a bit messy, but the abstraction is
> otherwise quite clean.
>
> -Eli