[cfe-dev] "generic" address space
Mon P Wang
wangmp at apple.com
Wed Jul 16 23:36:38 PDT 2008
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
>> 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
>> 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.
More information about the cfe-dev