Compiler option to control SYCL extensions.

[bader]

Today compiler has only two relevant options to turn on/off SYCL functionality:

Option	Description
-sycl-std=<value>	SYCL language standard to compile for
-fsycl-unnamed-lambda	Allow unnamed SYCL lambda kernels

-sycl-std today supports only one value: "1.2.1" (default) and doesn't really help to restrict functionality to SYCL 1.2.1 version.

I think it would be useful if compiler provides more fine grain control over developed SYCL extensions (e.g. unnamed-lambda #387, CTAD extensions #773, USM #256, etc.).

In addition to that, it would be great to align compiler option names with community way.
E.g. should we keep SYCL specific option -sycl-std or extend existing -std option (e.g. -std supports OpenCL standard versions, hip and cuda values).

Proposal

1. Extend -sycl-std= values with 1.2.1-ext, which should enable SYCL-1.2.1 functionality with extensions. In addition to that I think this should be a default value similar to how clang enables C++ extensions by default.
2. Add more options controlling extensions. TBD: define which extensions require compiler option. Some extensions do not require compiler support and can be controlled via define (e.g. Intel sub-groups).
3. Align options naming scheme with the clang community to simplify upsteaming.

Thoughts?

[AlexeySachkov]

Extend -sycl-std= values with 1.2.1-ext, which should enable SYCL-1.2.1 functionality with extensions. In addition to that I think this should be a default value similar to how clang enables C++ extensions by default.

What if user wants to use a particular set of extension?

Add more options controlling extensions.

Just an idea: -sycl-ext=+ext1,+ext2, similar to OpenCL

TBD: define which extensions require compiler option. Some extensions do not require compiler support and can be controlled via define (e.g. Intel sub-groups).

We could enable automatic passing of defines if extension is enabled (probably this will be easier for some users)

[bader]

Extend -sycl-std= values with 1.2.1-ext, which should enable SYCL-1.2.1 functionality with extensions. In addition to that I think this should be a default value similar to how clang enables C++ extensions by default.

What if user wants to use a particular set of extension?

I don't see any problems with that. Unused extensions do not affect final results. I think this proposal makes -sycl-std=1.2.1 valuable for code code portability among different SYCL implementations.

[AlexeySachkov]

Extend -sycl-std= values with 1.2.1-ext, which should enable SYCL-1.2.1 functionality with extensions. In addition to that I think this should be a default value similar to how clang enables C++

What if user wants to use a particular set of extension?

I don't see any problems with that. Unused extensions do not affect final results.

I think there might be problems, for example, by SYCL spec you cannot capture a pointer as kernel argument. However, it is legal in USM extension.

My point is that it might be not so clear which exact set of extensions are enabled and user might accidentally use more functionality from extensions than he thought/intended originally.

[rolandschulz]

Maybe we want both? We could add -sycl-std=1.2.1-ext to enable all and -sycl-ext=+ext1,+ext2 to enable (or disable) specific ones. I don't think we only want the option to enable them separately. For users who want all the usability improvements they should have an easy way to enable them all. Otherwise we are adding a new usability problem for novice users.

[asavonic]

Maybe we want both? We could add -sycl-std=1.2.1-ext to enable all and -sycl-ext=+ext1,+ext2 to enable (or disable) specific ones. I don't think we only want the option to enable them separately. For users who want all the usability improvements they should have an easy way to enable them all. Otherwise we are adding a new usability problem for novice users.

For OpenCL we also have -cl-ext=+all and -cl-ext=-all.

[asavonic]

Maybe we want both? We could add -sycl-std=1.2.1-ext to enable all and -sycl-ext=+ext1,+ext2 to enable (or disable) specific ones. I don't think we only want the option to enable them separately. For users who want all the usability improvements they should have an easy way to enable them all. Otherwise we are adding a new usability problem for novice users.

For OpenCL we also have -cl-ext=+all and -cl-ext=-all.

-cl-ext=+all,-cl_khr_fp16 is also supported.

[bader]

Summary of "SYCL upstream working group" discussion:

• All agree that we should have flags to turn on/off particular extensions.
• Flags controlling the same extensions might be set multiple multiple time in the same clang invocation - last one overrides previous flags.
• Hal: -fsycl-<extension> (e.g. -fsycl-usm) seems reasonable.
• Use __has_extension to detect if extension is supported in the source code.
• Hal general I'm okay to enable some extensions by default.
• Compatibility: Hal, for GCC compatibility we have different names - C++99 + GNU99.
• The same way we might have driver options compatibility with compute++ driver.
• Should be aligned with the clang convention to avoid user's hassle with two sets of flags.

[rolandschulz]

If we go with -fsycl-usm rather than -sycl-ext=+usm syntax how do we enable all extensions minus one specific one?

[AlexeySachkov]

If we go with -fsycl-usm rather than -sycl-ext=+usm syntax how do we enable all extensions minus one specific one?

-fsycl-all-extensions -fno-sycl-usm ?

[bader]

FYI: I'm trying to clarify clang community preference in this thread: http://lists.llvm.org/pipermail/cfe-dev/2019-November/064016.html.