[SYCL][Docs] Align kernel_args_restrict extension with SYCL 2020 to inherit critical fixes

[mkinsner]

Align kernel_args_restrict extension with fixes that we factored into SYCL2020, but didn't make it into this extension. Inherit the correct attribute location for function objects.

Signed-off-by: Michael Kinsner [email protected]

[gmlueck]

Since you are updating this extension doc anyway, can you use the new template and follow the conventions described in README-process?

[mkinsner]

Since you are updating this extension doc anyway, can you use the new template and follow the conventions described in README-process?

I have now updated to the latest template, so ready for review.

[gmlueck]

Thanks, Mike. This looks a lot better. A couple of comments below.

[gmlueck]

I'd suggest different wording here because:

• The phrase "pointer member of any accessors" is an implementation detail. We should just talk about "accessor" here, not about a member inside that accessor.

• There is no need to list all the ways that an application can pass a kernel argument. This is already defined in the core SYCL spec.

• We should not say that the attribute can be applied to arbitrary functions. We only define meaning in the case when it is applied to a kernel. The core SYCL spec already says:

  Applying these attributes to any language construct other than those specified in this section has implementation-defined effect.

I'd suggest something like this:

This extension adds a kernel function attribute that has similar effect as the C99 restrict type qualifier. When a kernel is decorated with this attribute, all pointers and accessors that are captured as kernel arguments and are used to write memory are assumed to point to disjoint objects in memory.

[mkinsner]

The phrase "pointer member of any accessors" is an implementation detail. We should just talk about "accessor" here, not about a member inside that accessor.

I like simplifying this, but we originally said "pointer member" because it isn't clear that applying restrict to an object wrapping a pointer has the necessary semantic. Restrict qualifies a pointer, which an accessor is not. Thoughts otherwise?

[gmlueck]

I agree that the C99 definition of restrict is defined in terms of pointers, so it's not really correct to say that this C++ attribute is "equivalent" to specifying restrict on each pointer and accessor argument. This is why I proposed the wording below that says "conceptually equivalent". I admit that this is not super precise, though.

Saying "pointer member" also seems wrong to me, though. For example, we have talked about changing the implementation of accessor, so that it internally contains two pointers. In such a case, those two internal pointers would alias each other.

I think a perfectly precise wording would require duplicating much of the wording for restrict, but rewording to say "pointer or accessor". I'm not opposed to this, but it will make the spec more verbose. (For reference, here is the cppreference link for restrict.)

Maybe there is some middle ground where we say something like:

Hint to the compiler that is equivalent to specifying the C99 restrict type qualifier to every pointer and accessor that is captured as an argument to this kernel function. Since the C99 definition of restrict applies only to pointers, each accessor must be considered a conceptual pointer for the purpose of this definition.

[mkinsner]

I think your latest suggestion would work. We could also go with more like:

This extension adds a kernel function attribute that has similar effect as the C99 restrict type qualifier. When a kernel is decorated with this attribute, all pointers and accessors (treated as if each accessor was a pointer) that are captured as kernel arguments and are used to write memory are assumed to point to disjoint objects in memory.

Preference?

[gmlueck]

Yes, that seems good.

[mkinsner]

I updated with the new wording, with the only exception that I removed "and are used to write memory". I don't think that's actually correct - all pointers should have the qualifier.

[gmlueck]

I'd suggest different wording here to for the same reasons I cite above. Maybe something like:

Hint to the compiler that is conceptually equivalent to specifying the C99 restrict type qualifier on every pointer or accessor that is captured as an argument to this kernel function.

[mkinsner]

Done

[gmlueck]

I still don't like this last sentence:

This effect is equivalent to annotating restrict on all kernel pointer arguments in an OpenCL or SPIR-V kernel.

There are two reasons I don't like it:

1. It's very unclear what this really means. This is a SYCL extension, not an OpenCL or SPIR-V extension. Users don't write OpenCL or SPIR-V directly. In fact, some of our targets don't use either of those underlying technologies. The semantics of the extension should be described purely in SYCL terms, not on some implementation detail that applies to only some targets.

2. If we assume this statement is talking about the SPIR-V code that is generated from SYCL, it's not strictly true. If we were to implement accessors with two internal pointers (which we have contemplated), then those two internal pointers would alias with one another. The [[intel::kernel_args_restrict]] attribute should still apply in this case. It means that the accessors don't alias. It doesn't provide a guarantee about all the internal pointers used to implement accessors.