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

[Eli Friedman via cfe-dev]

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

From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Bader, Alexey via cfe-dev
Sent: Monday, November 25, 2019 5:03 AM
To: clang-dev developer list <cfe-dev at lists.llvm.org>
Cc: Toguchi, Michael D <michael.d.toguchi at intel.com>
Subject: [EXT] [cfe-dev] [RFC][SYCL] Driver options to control non-standard features.

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/8611175f/attachment.html>