[RFC][SYCL] Driver options to control non-standard features

Clang Frontend
1

Hi,

I’d like to clarify the guidelines regarding clang driver option names for Clang extensions. We developed a number of options to control SYCL standard version and extensions to the SYCL standard features and we would like to make sure that these are aligned with the community expectations.

Options to turn on/off an individual extension of SYCL standard functionality

Naming convention we use for these options is to prefix option with -fsycl- prefix (e.g. -fsycl-usm, -fsycl-unnamed-lambda).

SYCL runtime library or application can check extension status via __has_extension macro (e.g. __has_extension(sycl_usm), __has_extension(sycl_unnamed_lambda)).

Some of SYCL extensions can be enabled by default.

Option to set SYCL standard version

Current implementation [1] supports -sycl-std= option name with only one supported value: 1.2.1 (default).

We are considering a new value “1.2.1-ext”, which will enable SYCL 1.2.1 features + a set of default extensions and “1.2.1” will restrict usage of non-standard features. “1.2.1-ext” is going to be a new default value.

Does it sound like something that can be accepted into the clang tree?

Open questions/alternatives

  • Should we extend/re-use existing options or add SYCL specific options? For instance, re-use -std to set SYCL standard version instead of adding -sycl-std. Or make -pedantic to warn about using SYCL extensions enabled by default.
  • Does it make sense to provide OpenCL-like single option to control individual extensions: -sycl-ext=”+,-,…” instead of adding -f[no-]sycl-, -f[no-]sycl-,… options.

Thanks,

Alexey

PS SYCL developers internal discussion can be found in this GitHub issue: https://github.com/intel/llvm/issues/806.

[1] https://github.com/intel/llvm/tree/sycl

[RFC] Add Full Support for the SYCL Programming Model
2

Language extensions/changes that need to be controlled on the command-line are generally controlled with “-f” options. I think we want to continue doing that.

For the standard version, it isn’t clear to me how tightly SYCL and the C++ standard version are tied together. Are the SYCL features supported orthogonal to the C++ language features supported? Does the SYCL standard require some specific version of C++? If it makes sense, then specifying the SYCL standard version in a separate flag is probably fine.

“1.2.1-ext” doesn’t really make sense, I think; we don’t want the “standard version” to refer to some unspecified set of extensions. If there’s a revised standard under development, it could make sense to refer to that before it’s finalized, though. For C++, for example, we have -std=c++2a to refer to the draft C++20 standard.

We don’t want to enable extensions by default unless they’re extensions the standard allows (for C++, that generally means that it uses some identifier reserved for the compiler).

-Eli

3

Hi Eli,

Thanks a lot of the feedback! A few more questions, if you allow.

Using “-f” options for language extensions for consistency sounds reasonable. We have a few cases not related to the source language:

  • We have a few options customizing clang driver workflow. E.g. option to emit only “accelerated/offloaded” code. Are there any guidelines for them? OpenMP seems to use -fopenmp- prefix for these. CUDA seems to use mix of -fcuda-* and just -cuda-*.
  • Do I understand correctly that options for passing options to other tools are prefixed with “-X”? E.g. pass options to “accelerator/vendor-specific” toolchain which is not part of the clang (similar to -Xopenmp-target) – link to the example in the source.
  • SYCL specification defines library API and some of the extensions might change standard API (changes might be incompatible with the standard version). What is the preferred way to control standard library changes?

Sorry for all these questions, but I couldn’t find any documentation for the compiler option naming convention.

For the standard version, it isn’t clear to me how tightly SYCL and the C++ standard version are tied together. Are the SYCL features supported orthogonal to the C++ language features supported? Does the SYCL standard require some specific version of C++? If it makes sense, then specifying the SYCL standard version in a separate flag is probably fine.

SYCL standard document defines C++ library interfaces and how the implementation using OpenCL for accelerating C++ lambdas/functors should behave. These library interfaces do not introduce any language extensions per se, but the use C++11 features like lambdas. Some of extensions to existing standard rely on C++14/C++17 features. This is the only dependency between C++ and SYCL.

To enable offloading of C++ code to accelerators, we added a couple of language attributes used for marking offloaded/accelerated parts of the code. In addition to that OpenCL based implementation sets additional restrictions on offloaded code like “offloaded lambda can’t capture raw pointers from the CPU”. Some OpenCL implementations share virtual memory between CPU (host) and accelerator (device) and we have a flag which removes some language restrictions (by disabling “standard” diagnostics) and extends standard library API. I’m not sure which category options like this fits into.

I’m okay to have a separate option for setting SYCL standard version, but the reason I raised this question is that implementation of options for other programming models for accelerators do not seems to follow a single pattern.

C/C++: -std set standard version + values for standard versions with gnu extensions.

OpenCL: -std + -cl-std. I assume -cl-std is supported because it’s mentioned in the OpenCL spec.

OpenMP: -fopenmp-version separate option

CUDA: no option to control different versions. It looks like the version is inferred from the CUDA SDK version and target architecture set via --cuda-path and --cuda-gpu-arch options.

SYCL: current implementation uses -sycl-std option name.

I think; we don’t want the “standard version” to refer to some unspecified set of extensions.

I thought it’s acceptable, but it might be that I just was confused by wording for C++ standard version options. https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Basic/LangStandards.def#L111

What does “ISO C++ 2011 with amendments” mean in -std=c++11 option description?

If there’s a revised standard under development, it could make sense to refer to that before it’s finalized, though. For C++, for example, we have -std=c++2a to refer to the draft C++20 standard.

  • What if feature was in the draft, but eventually wasn’t accepted? Can it be turned on for C++20 by a separate flag?

  • There are “vendor”-specific extensions, which are not going to proposed to the specification. Are these should be controlled by “-m”-prefixed options?

Thanks,
Alexey