[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#823810, @Anastasia wrote:

> In https://reviews.llvm.org/D28691#820684, @rjmccall wrote:
>
> > 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.
>
>
> The scope concept in OpenCL is fairly generic. And the builtins just take one extra argument on top of the existing C11 builtin style. The OpenCL scopes have of course specific meaning to the OpenCL model, but there is nothing preventing other uses of the scope feature.


Yes, it is possible that some other language could introduce exactly the same scope-atomics concept only with a slightly different enumeration of scopes.  But then we really shouldn't allow the OpenCL scopes to be used in that language, which means there would still not be a language-independent way of using these builtins.

> As far as I understand atomic scope implementation in LLVM is fairly generic wrt scope types and it is intended for broader functionality than just OpenCL.

In some ways this is reasoning the wrong way around.  I am not deeply informed about heterogenous computing, so I am happy to accept that llvm::SynchronizationScope is well-designed for our current needs.  But LLVM's representation is, by design, ultimately just an implementation detail and can be easily updated — it's just a matter of changing a few calls and adding an upgrade path to the bitcode loader, exactly as we did when we introduced llvm::SynchronizationScope.  That is not true of source language features, even builtins; their design is a contract with programmers, and the bar is substantially higher.

We do not have a compelling reason to claim that these are generally useful, so we should not.  They should stay namespaced and be flagged as language-specific builtins.

John.


https://reviews.llvm.org/D28691