Skip to content
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

[SYCL] Adding support for 'sycl_special_class' attribute. #3892

Merged
merged 117 commits into from
Oct 21, 2021

Conversation

zahiraam
Copy link
Contributor

@zahiraam zahiraam commented Jun 5, 2021

Special classes such as accessor, sampler, and stream need additional implementation when they are passed from host to device. Currently the compiler recognizes these classes by their name.
This patch is adding a new attribute “sycl_special_class” used to mark SYCL classes that need the additional compiler handling.
Usage:

class __attribute__((sycl_special_class)) class  special_class {
...
};

Fznamznon and others added 14 commits July 10, 2020 18:22
This attribute is used in SYCL headers to mark SYCL classes which need
additional compiler handling when passed from host to device.
Attribute can be applied to struct/class and can have optional argument
which indicates kind of SYCL special class, so it can be used to
implement handling of some generic case of SYCL special class as well as
implement different handling for each kind of SYCL special class.

Usage:
```
class __attribute__((sycl_special_class(accessor))) accessor {
...
}
```
Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
@zahiraam
Copy link
Contributor Author

zahiraam commented Jun 15, 2021

@Fznamznon
I have incorporated the code from #2091

There are still some issues. I am trying to compile this test case:

#include "sycl.hpp"

sycl::queue myQueue;

class __attribute__((sycl_special_class(accessor))) AccessorBase {
  int A;
public:
  sycl::accessor<int, 1, sycl::access::mode::read_write,
                 sycl::access::target::local>
  acc;
};

int main() {

  AccessorBase AS;
  myQueue.submit([&](sycl::handler &h) {
    h.single_task<class XYZ>([=]() {
      AS.acc.use();

    });
  });

  return 0;
}

First is this a legal test case? If it is, I am expecting that the __init method be created. But it crashing with an assert at handleSpecialType because InitMethod is null.

The same test using class AccessorBase instead, is creating the __init method. As far as I can tell, it is happening during the call to visitRecord. With the attribute sycl_special_class(accessor) , the call to the function visitRecord doesn’t happen before handleSpecialType. And this function is using the InitMethod. What am I missing? Should handleSpecialType call visitRecord?
Any comments/suggestions are welcome.

@zahiraam
Copy link
Contributor Author

@erichkeane Would you mind taking a loot at this and give me some feedback. I have added the attribute, but getting a crash in the handleSpecialType because the __init function is not created. Can you please let me know if the test case I am using (comment above) is actually correct and what I am missing? thanks.

@Fznamznon
Copy link
Contributor

Please keep in mind the idea described by Victor here #2091 (comment) , so the original patch needs rework.

First is this a legal test case? If it is, I am expecting that the __init method be created. But it crashing with an assert at handleSpecialType because InitMethod is null.

It should be defined by the class that have sycl_special_class attribute, so it seems the test case you mentioned is not completely valid. FE job here is only generate a call to __init method.

@erichkeane
Copy link
Contributor

Please keep in mind the idea described by Victor here #2091 (comment) , so the original patch needs rework.

First is this a legal test case? If it is, I am expecting that the __init method be created. But it crashing with an assert at handleSpecialType because InitMethod is null.

It should be defined by the class that have sycl_special_class attribute, so it seems the test case you mentioned is not completely valid. FE job here is only generate a call to __init method.

Yep, exactly this. Any types with this attribute need to have their __init method DEFINED. The attribute then is supposed to cause the SemaSYCL visitor handling to emit a call to said __init method.

@zahiraam
Copy link
Contributor Author

zahiraam commented Jun 16, 2021

@erichkeane Ok thanks.
You say "Any types with this attribute need to have their __init method DEFINED"
Where does this happen? Still not quite clear about this. Should I have a function instantiateSYCLSpecialClassAttr function?

@erichkeane
Copy link
Contributor

@erichkeane Ok thanks.
You say "Any types with this attribute need to have their __init method DEFINED"
Where does this happen? Still not quite clear about this. Should I have a function instantiateSYCLSpecialClassAttr function?

In the source code? Check out how accessor is implemented today. It needs to still have that __init method.

The point of this patch is for the library code to still be more or less like it is now, except with the added attribute so that we're not detecting these 'special' types directly by name.

Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
@zahiraam zahiraam changed the title Pr 2091 [SYCL] Adding support for sycl_special_class attribute. Jun 17, 2021
@zahiraam zahiraam changed the title [SYCL] Adding support for sycl_special_class attribute. [SYCL] Adding support for 'sycl_special_class' attribute. Jun 17, 2021
Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
@zahiraam zahiraam marked this pull request as ready for review June 18, 2021 17:24
Copy link
Contributor

@smanna12 smanna12 left a comment

Choose a reason for hiding this comment

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

@zahiraam, you need to add // clang-format on line1597 instead of line#1588

@elizabethandrews
Copy link
Contributor

@zahiraam, you need to add // clang-format on line1597 instead of line#1588

@smanna12 is this the norm for clang-format fails? As in, are we expected to add these comments?

Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
@smanna12
Copy link
Contributor

smanna12 commented Oct 14, 2021

@zahiraam, you need to add // clang-format on line1597 instead of line#1588

@smanna12 is this the norm for clang-format fails? As in, are we expected to add these comments?

I remember that i did this on one of my PR #2399 suggested by reviewer. I am not sure whether this is the norm for clang-format fails. Tagging @bader for this specific question?

@keryell
Copy link
Contributor

keryell commented Oct 14, 2021

I remember that i did this on one of my PR #2399 suggested by reviewer. I am not sure whether this is the norm for clang-format fails. Tagging @bader for this specific question?

Interesting. Perhaps this is solved by using latest clang-format-14 from HEAD?

@zahiraam
Copy link
Contributor Author

I remember that i did this on one of my PR #2399 suggested by reviewer. I am not sure whether this is the norm for clang-format fails. Tagging @bader for this specific question?

Interesting. Perhaps this is solved by using latest clang-format-14 from HEAD?

@keryell Yes that's the version I am using!

@bader
Copy link
Contributor

bader commented Oct 15, 2021

@zahiraam, you need to add // clang-format on line1597 instead of line#1588

@smanna12 is this the norm for clang-format fails? As in, are we expected to add these comments?

I remember that i did this on one of my PR #2399 suggested by reviewer. I am not sure whether this is the norm for clang-format fails. Tagging @bader for this specific question?

I don't think we should apply suggestion for the test from #2399 for DCP++ runtime headers. @intel/llvm-reviewers-runtime, does this suggestion works for you?

@romanovvlad
Copy link
Contributor

@zahiraam, you need to add // clang-format on line1597 instead of line#1588

@smanna12 is this the norm for clang-format fails? As in, are we expected to add these comments?

I remember that i did this on one of my PR #2399 suggested by reviewer. I am not sure whether this is the norm for clang-format fails. Tagging @bader for this specific question?

I don't think we should apply suggestion for the test from #2399 for DCP++ runtime headers. @intel/llvm-reviewers-runtime, does this suggestion works for you?

Do not think we should do it for runtime headers either.

Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
@zahiraam
Copy link
Contributor Author

@zahiraam, you need to add // clang-format on line1597 instead of line#1588

@smanna12 is this the norm for clang-format fails? As in, are we expected to add these comments?

I remember that i did this on one of my PR #2399 suggested by reviewer. I am not sure whether this is the norm for clang-format fails. Tagging @bader for this specific question?

I don't think we should apply suggestion for the test from #2399 for DCP++ runtime headers. @intel/llvm-reviewers-runtime, does this suggestion works for you?

Do not think we should do it for runtime headers either.

Removing the clang-format directives and fixing lines 1575 didn't work. I am going for the more aggressive indentation fix even if it looks like an "unrelated" change. clang-format thinks that it is!

Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
@bader
Copy link
Contributor

bader commented Oct 15, 2021

@zahiraam, you need to add // clang-format on line1597 instead of line#1588

@smanna12 is this the norm for clang-format fails? As in, are we expected to add these comments?

I remember that i did this on one of my PR #2399 suggested by reviewer. I am not sure whether this is the norm for clang-format fails. Tagging @bader for this specific question?

I don't think we should apply suggestion for the test from #2399 for DCP++ runtime headers. @intel/llvm-reviewers-runtime, does this suggestion works for you?

Do not think we should do it for runtime headers either.

Removing the clang-format directives and fixing lines 1575 didn't work. I am going for the more aggressive indentation fix even if it looks like an "unrelated" change. clang-format thinks that it is!

The suggested change doesn't look correct to me. It seems that ifdef directive confuses clang-format. I suggest we discuss this issue in separate PR as it's not related here. I'm okay to ignore clang-format failure.

Signed-off-by: Zahira Ammarguellat <zahira.ammarguellat@intel.com>
@elizabethandrews
Copy link
Contributor

Actually, can you update your PR description - that will be the commit message. It is currently outdated.

@bader
Copy link
Contributor

bader commented Oct 19, 2021

@againull, @intel/llvm-reviewers-runtime, ping.

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.