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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
