Skip to content

[SYCL][DOC] Add extension for annotated_ptr class and its properties #5755

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 57 commits into from
Dec 15, 2022

Conversation

tiwaria1
Copy link
Contributor

@tiwaria1 tiwaria1 commented Mar 8, 2022

Introduce three new extensions:

  1. sycl_ext_oneapi_annotated_ptr
    Introduces a pointer wrapper class that provides a mechanism to attach compile-time constant information to a pointer in a manner that allows the compiler to reliably maintain and analyze the information.

  2. sycl_ext_intel_fpga_kernel_arg_properties
    Defines additional supported properties for annotated_ptr and annotated_arg classes. This commit will remove the extension sycl_ext_intel_fpga_annotated_arg_properties.

  3. sycl_ext_oneapi_kernel_arg_restrict_property
    Defines the restrict property for annotated_ptr and annotated_arg classes in a separate extension rather than including it in sycl_ext_intel_fpga_kernel_arg_properties so that vendors can support the property without having to support FPGA specific properties.

This commit also updates the annotated_arg extension to remove function overloads that are not needed.

@tiwaria1
Copy link
Contributor Author

tiwaria1 commented Mar 8, 2022

Working on:

  • Double check that extension aligns with latest template.
  • Update the properties syntax based on recent changes to the design of compile-time properties.

@tiwaria1
Copy link
Contributor Author

tiwaria1 commented Apr 13, 2022

@gmlueck , @GarveyJoe Please do another round of review. I have addressed your comments and added FPGA properties as a separate extension.

@@ -23,7 +23,7 @@
== Notice

[%hardbreaks]
Copyright (c) 2021-2022 Intel Corporation. All rights reserved.
Copyright (c) 2022-2022 Intel Corporation. All rights reserved.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just Copyright (c) 2022 Intel Corporation.?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


// alignment in bytes and address bus width of the pointer specified using the
// properties 'alignment' and 'awidth'.
// a properties object is deducted from the list the of property values
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// a properties object is deducted from the list the of property values
// a properties object is deduced from the list the of property values

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@broxigarchen
Copy link
Contributor

Hi @steffenlarsen @Pennycook Please let me know your thoughts on this PR. Thanks!

Copy link
Contributor

@Pennycook Pennycook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to block this. The only things I could spot were related to names.

Comment on lines +215 to +224
template<read_write_mode_enum mode>
inline constexpr read_write_mode_key::value_t<mode>
read_write_mode;
inline constexpr read_write_mode_key::value_t<
read_write_mode_enum::read> read_write_mode_read;
inline constexpr read_write_mode_key::value_t<
read_write_mode_enum::write> read_write_mode_write;
inline constexpr read_write_mode_key::value_t<
read_write_mode_enum::read_write>
read_write_mode_readwrite;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

read_write_mode_readwrite is a really bad name.

Would it make sense to split this out into separate read, write and read_write properties?

inline constexpr wait_request_key::value_t<true>
wait_request_requested;
inline constexpr wait_request_key::value_t<false>
wait_request_not_requested;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the name wait_request_not_requested really confusing, and I don't think this convenience type helps.

The second use of "requested" doesn't seem to be tied to the first use of "request", and the description of wait_request later in the document talks about whether the wait request signal is generated rather than requested. wait_request<true> is also shorter.

Copy link
Contributor

@steffenlarsen steffenlarsen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My concerns have been addressed, so LGTM! That said, I agree with @Pennycook on the property shorthand namings.

@pvchupin pvchupin merged commit b423e1d into intel:sycl Dec 15, 2022
againull pushed a commit that referenced this pull request Jan 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants