[cfe-dev] Ideas for enabling builtin fucntions to accept non-zero address spaces

[Tom Stellard]

Hi,

I'm looking for suggestions for how to get builtin functions to accept pointers
with non-zero address spaces.  The reason I would like to do this is
so I can use __builtin_nanf() from OpenCL C.

This currently does not work, because in OpenCL all string literals are
stored in the constant address space.  For example:

kernel void test(global float* out) {
  out[0] = __builtin_nanf("");
  }

test.cl:3:27: error: passing '__constant char *' to parameter of type
                     'const char *' changes address space of pointer


So far I have had two ideas.  The first was this:

--- a/include/clang/AST/Type.h
+++ b/include/clang/AST/Type.h
@@ -422,7 +422,7 @@ public:
   /// Generally this answers the question of whether an object with the
   //other
   /// qualifiers can be safely used as an object with these qualifiers.
   bool compatiblyIncludes(Qualifiers other) const {
-    return isAddressSpaceSupersetOf(other) &&
+    return (!hasAddressSpace() || isAddressSpaceSupersetOf(other)) &&
            // ObjC GC qualifiers can match, be added, or be removed,
            // but can't
            // be changed.
            (getObjCGCAttr() == other.getObjCGCAttr() || !hasObjCGCAttr() ||



This intention of this change was to make it so that pointer types with no
address space qualifier are considered compatible to pointers with
address space qualifiers.  This fixed my example, but broke
several existing address space tests.


The second idea I had was to create a FunctionDecl for the builtin which
matched the arguments used in the CallExpr.  This would have the effect
of creating an overloaded version of the builtin with the correct
address space on the fly.  I thought I could do this in
Sema::LazilyCreateBuiltin(), but I couldn't figure out how to get
a reference to the CallExpr that triggered the FunctionDecl to be
created.


Do either of these approaches make sense?  Does anyone have a better
idea for implementing this?

Thanks,
Tom