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

[Bader, Alexey via cfe-dev]

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=<value> 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="+<extension1>,-<extension2>,..." instead of adding -f[no-]sycl-<extension1>, -f[no-]sycl-<extension2>,... 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191125/6267bc00/attachment.html>