[SYCL] Use of OpenCL_CPP source language in SPIR-V binaries

[kpet]

OpenCL_CPP is currently used as the Source Language reported via OpSource in SPIR-V modules. I'm wondering whether it'd make sense to introduce a SYCL Source Language to SPIR-V? (cc @bashbaug)

[bader]

Our SYCL implementation uses Source Language for one reason only - to enable translation of mangled user functions in SPIR-V translator.

SPIR-V translator has two modes:

• C mode: in this mode only "built-in functions " can be mangled, so translator unmangles the name and tries to map the built-in to corresponding SPIR-V instruction
• C++ mode: in this mode translator uses SPIR-V representation in LLVM IR to detect the "builtins", which we are supposed to map to SPIR-V instructions.

LLVM IR produced by C++ front-end can't be translated in "C mode".

If we can come-up with SPIR-V instructions representation in LLVM IR unified for all languages (C/C++/Fortran/etc), we can use Source Language only for "debugging purposes" as defined by SPIR-V spec.

[kpet]

Thanks for the background! Technically, this is not a valid use of OpSource. The spec says:

This has no semantic impact and can safely be removed from a module.

Two questions that come to mind:

• Could/should the information be passed via an option to the translator?
• Wouldn't it be possible to have the translator behave in the same way with another Source Language as well?

This is not the most important thing in the world but, between the defunct OpenCL C++ 1.0, C++ for OpenCL and SYCL, OpenCL_CPP is starting to become quite overloaded :).

[bader]

Technically, this is not a valid use of OpSource. The spec says:

This has no semantic impact and can safely be removed from a module.

Technically, SYCL compiler sets named metadata in LLVM module, which is translated to OpSource SPIR-V instruction. In other word we exploit existing SPIR-V translator behavior, which might be considered as "not valid" :-). I mean SPIR-V translator interprets LLVM IR differently based on named mode metadata.

Could/should the information be passed via an option to the translator?

I assume by "the information" you mean "C or C++ mode". Technically "yes", but I believe that making SPIR-V translator agnostic to the front-end emitting LLVM IR is much cleaner and easier to maintain design. Today translator support different representation of the same SPIR-V instruction for C and C++ modes (e.g. "_Z7barrier*" for C and "_Z*__spirv_OpControlBarrier*" for C++ mode). It's not scaleable. Ideally there should be a single representation suitable for any FE (e.g. llvm.barrier or llvm.spirv.barrier).

Wouldn't it be possible to have the translator behave in the same way with another Source Language as well?

It would be possible if we avoid conflicts in representation for SPIR-V instructions and user symbols. The reason "SPIR-V representation in LLVM IR" was introduced is - "C mode" representation conflicts with user function. For example, "_Z7barrier*" - user functions are not overloaded in C, so using this definition for SPIR-V instructions is okay for "C mode", but it's conflict with "barrier()" user function declaration in C++/SYCL mode.

This is not the most important thing in the world but, between the defunct OpenCL C++ 1.0, C++ for OpenCL and SYCL, OpenCL_CPP is starting to become quite overloaded :).

AFAIK, OpSource is ignored in our tools. Is it used in some other tools you are caring about?

[kpet]

Oh, I see, thanks for clarifying. I initially thought you were using OpSource to pass information to the consumer and assuming it was the SPIR-V LLVM translator. That would have been bad :).

It's not scaleable. Ideally there should be a single representation suitable for any FE

Yup, agree.

Is it used in some other tools you are caring about?

No, I'm only reporting this as having a dedicated SYCL Source Language would make it easier to get an idea of the provenance of a SPIR-V module examined in isolation. It's merely for clarity/convenience.

There's no reason the translator should choose OpenCL_CPP in this C++ mode even. These needn't be related.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be automatically closed in 30 days.

[kpet]

This was automatically marked as stale, commenting so the issue doesn't get closed. I've requested a SYCL SPIR-V SourceLanguage with KhronosGroup/SPIRV-Headers#270

[kpet]

The change to the SPIRV-Headers has now been merged. I'm guessing the next step is probably to add support to the SPIRV-LLVM-Translator, isn't it?

[MrSidims]

@kpet @bader currently the translator can differentiate Source Languages by either OpenCL version metadata or by !DICompileUnit DWARF metadata. From what I see, we can't really distinguish SYCL from regular C++ (and it's kind of a part of our design, isn't it?) in LLVM IR. I suggest to introduce an OpenCL-like metadata that can be emitted by clang (itcan also encode information about SYCL version). Without such metadata I see no ways to preserve this information through SPIR-V.