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

[Neil Henning]

I used to hack around this with an address space cast on the "", but now 
I just use an integer NaN value bitcasted to a float to 'solve' this. A 
proper solution would be welcome though.

I think this change you are requesting could be generalized to more 
builtins though - for instance being able to use atomic intrinsics on 
multiple address spaces would also be really useful.

-Neil.

On 03/03/2015 16:55, Tom Stellard wrote:
> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev