[PATCH] D76620: [SYCL] Implement __builtin_unique_stable_name.

Erich Keane via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Oct 13 05:58:26 PDT 2020


erichkeane added a comment.

In D76620#2326551 <https://reviews.llvm.org/D76620#2326551>, @rsmith wrote:

> In D76620#2324858 <https://reviews.llvm.org/D76620#2324858>, @erichkeane wrote:
>
>> The feature that this supports is a part of the SYCL 2020 Provisional Spec, I thought that was sufficient.  We'll look into an RFC to re-submit in the future.
>
> Does that cover only functionality that can be implemented in terms of this builtin, or the builtin itself? If so, what is the functionality that needs to be supported? That information will be a good starting point for the RFC.

Functionality that is implemented in terms of this builtin.  Basically: When compiling a SYCL program, we do so in 2 invocations, once for the Host and once for the Device.  The 'sycl_kernel' is the interface function that both invocations of the compiler need to know the name of.  For the most part, using the the mangled name of the functor would work, except when using lambdas, where the name is not sufficiently stable, and frequently changes across invocations (even further so when there is macros that introduce lambdas above/below it).

The earlier SYCL spec gets around this by requiring the user to specify a unique-name for the kernel name themselves, in a way that is otherwise unused, something like:
`kernel_call<class ANameIGuaranteeIsUnique>([](){});`

The 2020 spec supports removing the specific name (so that `kernel_call([](){})` works).  In order to do that, we need some interface that provides a name based on the functor that is both unique and stable. As I mentioned before, lambdas proved difficult, so we added a builtin to produce a string version of the name (that the host runtime can then use to lookup the kernel later), and the implementation of it in SEMA is used to generate the kernel's name.

> In D76620#2326499 <https://reviews.llvm.org/D76620#2326499>, @keryell wrote:
>
>> Otherwise, just removing a feature used for almost 6 months will cause some kind of forking pain...
>
> Well, there have at least not been any LLVM releases with this feature yet. (We're on the cusp of releasing LLVM 11, which would be the first release with this functionality.)

In fairness, all of the downstreams that I'm aware for SYCL of are working off of trunk. For my two downstreams, this is only a mild inconvenience.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76620/new/

https://reviews.llvm.org/D76620



More information about the cfe-commits mailing list