[PATCH] D28691: Add OpenCL 2.0 atomic builtin functions as Clang builtin

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D28691#820641, @b-sumner wrote:

> In https://reviews.llvm.org/D28691#820595, @rjmccall wrote:
>
> > In https://reviews.llvm.org/D28691#820541, @b-sumner wrote:
> >
> > > There are other languages for heterogeneous compute that have scopes, although not exposed quite as explicitly as OpenCL.  For example AMD's "HC" language.  And any language making use of clang and targeting SPIR-V would likely use these builtins.  I think a more generic prefix is appropriate, and "scoped" tells us exactly when these are needed.
> >
> >
> > But would those languages use the same language design for these scopes as OpenCL if they did expose them, as opposed to some more elaborate scoping specification?  My objection is not that the concept is inherently OpenCL-specific, it's that the presentation in the language might be inherently OpenCL-specific, which makes staying in the opencl namespace is prudent.
>
>
> Are you envisioning a language far enough from C/C++ that a standard library or header would not be able to map a scoped atomic operation into a call to one of these new builtins?  Would we expect more of such languages than languages that would do such a mapping?


If you're using Clang as a frontend for your language, it must be similar enough to C to call a builtin function.  That's not at issue.  The central question here is whether these builtins are meaningfully general outside of OpenCL.  The concept of heterogenous computation is certainly not specific to OpenCL;  however, these builtins are defined in terms of scopes — "work item", "work group", "device", and "all svm devices" — which, it seems to me, are basically only defined by reference to the OpenCL architecture.  A different heterogenous compute environment might reasonably formalize scopes in a completely different way; for example, it might wish to be more explicit about exactly which peers / devices to synchronize with.

SPIR is explicitly defined on top of the OpenCL model.  Users should be able to use OpenCL builtins when targeting it.  That does not make those builtins more general than OpenCL.

John.


https://reviews.llvm.org/D28691