Add static constexpr members dimensions, access_mode and access_target to accessor class spec

[lbushi25]

This PR addresses #270. It follows in the footsteps of #351.
I think this will require CTS changes as well but I can't add the label myself.

[CLAassistant]

All committers have signed the CLA.

[keryell]

That looks like a good starting point.

[keryell]

For dimensions we could use mdspan equivalent https://en.cppreference.com/w/cpp/container/mdspan/extents/rank but unfortunately it relies on C++23 constexpr static access through this.

[gmlueck]

I think we should also add these static constexpr members to the other forms of accessors for consistency:

• host_accessor (section 4.7.6.10)
• local_accessor (section 4.7.6.11)
• unsampled_image_accessor and host_unsampled_image_accessor (section 4.7.6.13)
• sampled_image_accessor and host_sampled_image_accessor (section 4.7.6.14)

And also in these deprecated accessor specializations:

• The target::constant_buffer specialization (section 4.7.6.9.4.5)
• The target::host_buffer specialization (section 4.7.6.9.4.6)
• The target::local specialization (section 4.7.6.9.4.7)

[gmlueck]

Note that the sycl:: namespace is not strictly necessary here. It could be like this:

static constexpr access_mode access_mode = AccessMode;

But maybe the sycl:: is better for clarity anyway.

I was concerned at first that this definition of access_mode will shadow the type sycl::access_mode for any code inside this class. I think this will not affect the specification, though, because none of the member function parameter or return types use access_mode. Of course, implementations will likely need to change because they undoubtedly use the access_mode type in their implementations. I think that is OK, though. Raising the shadowing issue here, though, in case others see some problem.

[Pennycook]

I don't know if shadowing is a problem or not, but if it is then I think we already have it, because multi_ptr defines:

static constexpr access::address_space address_space = Space;

I'm just pointing that out because if we decide to do something different here, we may need to revisit multi_ptr.

[tomdeakin]

@lbushi25 - are you able to sign the CLA for this contribution?

[lbushi25]

@lbushi25 - are you able to sign the CLA for this contribution?

Done, thanks for the reminder!

[tomdeakin]

The WG discussed this. Next steps: add these to the other accessors types.

[lbushi25]

I think we should also add these static constexpr members to the other forms of accessors for consistency:

• host_accessor (section 4.7.6.10)
• local_accessor (section 4.7.6.11)
• unsampled_image_accessor and host_unsampled_image_accessor (section 4.7.6.13)
• sampled_image_accessor and host_sampled_image_accessor (section 4.7.6.14)

And also in these deprecated accessor specializations:

• The target::constant_buffer specialization (section 4.7.6.9.4.5)
• The target::host_buffer specialization (section 4.7.6.9.4.6)
• The target::local specialization (section 4.7.6.9.4.7)

I have added the members for other accessor types. I cannot seem to find the deprecated specialization of accessors in the second part of your comment. Since this is old, I'm assuming they have been removed already?

[lbushi25]

I think we should also add these static constexpr members to the other forms of accessors for consistency:

• host_accessor (section 4.7.6.10)
• local_accessor (section 4.7.6.11)
• unsampled_image_accessor and host_unsampled_image_accessor (section 4.7.6.13)
• sampled_image_accessor and host_sampled_image_accessor (section 4.7.6.14)

And also in these deprecated accessor specializations:

• The target::constant_buffer specialization (section 4.7.6.9.4.5)
• The target::host_buffer specialization (section 4.7.6.9.4.6)
• The target::local specialization (section 4.7.6.9.4.7)

I have added the members for other accessor types. I cannot seem to find the deprecated specialization of accessors in the second part of your comment. Since this is old, I'm assuming they have been removed already?

@gmlueck ping for awareness.

[gmlueck]

Thanks, @lbushi25, those changes look good.

I have added the members for other accessor types. I cannot seem to find the deprecated specialization of accessors in the second part of your comment. Since this is old, I'm assuming they have been removed already?

They are still in the spec. Deprecated features will not ever be removed from the SYCL 2020 spec (though they may be removed in future versions of the SYCL spec). The relevant source file headers are:

• headers/accessorDeprecatedConstant.h
• headers/accessorDeprecatedHost.h
• headers/accessorDeprecatedLocal.h

The WG always asks about CTS coverage before approving spec clarifications now. Do you know if we have tests that cover these member variables already?

[TApplencourt]

Gentle ping @lbushi25 : )

[lbushi25]

Gentle ping @lbushi25 : )

Will make the changes soon as I have been on vacation.

[lbushi25]

Gentle ping @lbushi25 : )

Will make the changes soon as I have been on vacation.

I made the changes.

[lbushi25]

Thanks, @lbushi25, those changes look good.

I have added the members for other accessor types. I cannot seem to find the deprecated specialization of accessors in the second part of your comment. Since this is old, I'm assuming they have been removed already?

They are still in the spec. Deprecated features will not ever be removed from the SYCL 2020 spec (though they may be removed in future versions of the SYCL spec). The relevant source file headers are:

• headers/accessorDeprecatedConstant.h
• headers/accessorDeprecatedHost.h
• headers/accessorDeprecatedLocal.h

The WG always asks about CTS coverage before approving spec clarifications now. Do you know if we have tests that cover these member variables already?

I seem to have missed the CTS coverage question, sorry about that. No, I don't think we have such tests.

[gmlueck]

I seem to have missed the CTS coverage question, sorry about that. No, I don't think we have such tests.

Could you add some, please?