Skip to content

[SYCL] SemaSYCL significant refactoring #1517

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 39 commits into from
Apr 22, 2020
Merged

Conversation

Fznamznon
Copy link
Contributor

@Fznamznon Fznamznon commented Apr 14, 2020

This is part of refactoring started here - #1495 .

The integration header and OpenCL generation code has evolved over time to become convoluted and difficult to maintain. It doesn't properly handle the recursive nature of types in many cases as it seems to do so on a mostly ad-hoc basis. It also has a fairly sizable use of recursive lambdas that are both difficult to read and painful to modify. The variety of checks and processings are unfortunately mixed to the point where it is difficult to follow the path through the code.

This patch replaces the existing implementation with a series of visitor types and infrastructure with which to properly iterate and recurse through the kernel lambda objects. It also better splits up the responsibilities through the visitor types, with a separate one for type checking, kernel declaration generation, kernel body generation, and integration header generation. These types have minimal interaction between them.

The visitor pattern also vastly simplifies how each type is handled, since each type has its own handling function, it is only required for an implementer of the visitor to handle one type at a time.

Overall, we hope that this will result in a significantly easier to maintain, modify, and review infrastructure for this functionality.

Erich Keane and others added 18 commits April 14, 2020 07:43
Signed-off-by: Erich Keane <erich.keane@intel.com>
Signed-off-by: Erich Keane <erich.keane@intel.com>
…or. Still need IntHeader and kernel body generation

Signed-off-by: Erich Keane <erich.keane@intel.com>
Signed-off-by: Erich Keane <erich.keane@intel.com>
Signed-off-by: Erich Keane <erich.keane@intel.com>
Signed-off-by: Erich Keane <erich.keane@intel.com>
Signed-off-by: Erich Keane <erich.keane@intel.com>
…ill need to fix the integration header offset calculation/keeping track

Signed-off-by: Erich Keane <erich.keane@intel.com>
…. Quitting for the weekend, pushing so that others can have a look at the progress/help how they can
Signed-off-by: Erich Keane <erich.keane@intel.com>
Signed-off-by: Erich Keane <erich.keane@intel.com>
Signed-off-by: Erich Keane <erich.keane@intel.com>
…y creator to get the list of parameters for the currently handled field

Signed-off-by: Erich Keane <erich.keane@intel.com>
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
@Fznamznon Fznamznon requested a review from erichkeane as a code owner April 14, 2020 13:55
Copy link
Contributor

@erichkeane erichkeane left a comment

Choose a reason for hiding this comment

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

This seems like a good first run. It would be nice if we could minimize the amount of data each of these had to store.

Otherwise, good job!

Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
This reverts commit c4da2ce.
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
@Fznamznon
Copy link
Contributor Author

Hm, something is wrong with unnamed lambdas.

@erichkeane
Copy link
Contributor

Hm, something is wrong with unnamed lambdas.

I haven't been building this lately, is there a test fail you're referring to? Do you want me to take a look?

@erichkeane
Copy link
Contributor

@elizabethandrews : wanna give this a once over for me too? Otherwise @bader, I think this is likely ready!

Note the check_pr test failure is because I didn't sign some of the patches, but a merge will squash them anyway.

@elizabethandrews
Copy link
Contributor

@elizabethandrews : wanna give this a once over for me too? Otherwise @bader, I think this is likely ready!

Note the check_pr test failure is because I didn't sign some of the patches, but a merge will squash them anyway.

Yes. I'm taking a look. I'm not as fast as you both! So you end up saying what I had flagged for review before I post :)

Copy link
Contributor

@bader bader left a comment

Choose a reason for hiding this comment

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

While we are still reviewing - a couple of minor comments from me.
I think we need further simplify this file, but it's a separate PR.

@@ -1,4 +1,4 @@
// RUN: %clang -I %S/Inputs -fsycl-device-only -Xclang -fsycl-int-header=%t.h %s -c -o %T/kernel.spv
// RUN: %clang -I %S/Inputs -fsycl-device-only -Xclang -fsycl-int-header=%t.h %s -fsyntax-only -o %T/kernel.spv
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
// RUN: %clang -I %S/Inputs -fsycl-device-only -Xclang -fsycl-int-header=%t.h %s -fsyntax-only -o %T/kernel.spv
// RUN: %clang -I %S/Inputs -fsycl-device-only -Xclang -fsycl-int-header=%t.h %s -fsyntax-only

I would also add following TODOs for the follow-up improvements:

  • I would also bypass the driver and use %clang_cc1.
  • It's looks strange the we use -fsyntax-only in CodeGen test. I think we should address this by moving integration header generation to CodeGen library.

Copy link
Contributor

Choose a reason for hiding this comment

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

@Fznamznon for the TODOs.

Do we have a good way of moving it architected. I cannot think of a good way to move integration headers generation later in the process.

As far as using fsyntax-only in the CodeGen test, yes, this is weird. I'm not convinced that this test should BE a CodeGen test as opposed to a SEMA test.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can't say if there is a good way to move integration header generation to the CodeGen or not, since I don't know all parts of the clang good enough. But I wouldn't refuse considering it.
IMO generation of some code in Sema seems weird for me (it has been weird ever since it appeared, but I didn't come up other suggestion so here it is). See https://clang.llvm.org/docs/InternalsManual.html#the-sema-library, it says that Sema does semantic analysis and builds AST.
I think we can create an issue to investigate this approach (maybe asking the community about it) at least, instead of leaving TODO in the test that no one ever looks at.

Copy link
Contributor

Choose a reason for hiding this comment

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

You're right that conceptually it could be in CodeGen (though, most call Clang Codegen "IR-Gen", since it doesn't generate 'code', it generates IR).

But I just don't see a good way to do it. And splitting it from the rest of the kernel generation(which it is so closely related to) is perhaps a bad idea as well. We should ask community when we come to open sourcing it, though I'm unconvinced "CodeGen" is the right place.

Copy link
Contributor

@elizabethandrews elizabethandrews left a comment

Choose a reason for hiding this comment

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

Just a few nits.

Erich Keane and others added 4 commits April 21, 2020 09:22
Since the only caller to this now uses both values, refactor it to just
return a pair and unpack on the other side.

Signed-off-by: Erich Keane <erich.keane@intel.com>
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
bader
bader previously approved these changes Apr 21, 2020
@bader bader requested a review from erichkeane April 21, 2020 10:34
erichkeane
erichkeane previously approved these changes Apr 21, 2020
Signed-off-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
@Fznamznon Fznamznon dismissed stale reviews from erichkeane and bader via b0a03e6 April 22, 2020 09:10
@Fznamznon Fznamznon requested review from bader and erichkeane April 22, 2020 11:07
Copy link
Contributor

@erichkeane erichkeane left a comment

Choose a reason for hiding this comment

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

I didn't see the windows test failure, but I'm surprised you had to do that... Did I do something in the test that changed layouts in windows?

@Fznamznon
Copy link
Contributor Author

I didn't see the windows test failure, but I'm surprised you had to do that... Did I do something in the test that changed layouts in windows?

No the windows failure was my fault. I changed test run line so it is run without the clang driver and forgot the triple because with the clang driver it is passed automatically. It caused windows mangling for kernel names and test started failing.

@erichkeane
Copy link
Contributor

I didn't see the windows test failure, but I'm surprised you had to do that... Did I do something in the test that changed layouts in windows?

No the windows failure was my fault. I changed test run line so it is run without the clang driver and forgot the triple because with the clang driver it is passed automatically. It caused windows mangling for kernel names and test started failing.

Ah, that makes more sense :) Thanks for clarifying. @bader ready when you are :)

@bader
Copy link
Contributor

bader commented Apr 22, 2020

Could you help me to write a good commit message for this patch, please?
I would appreciate if you could update the description with the summary of the changes done in this refactoring.

@erichkeane
Copy link
Contributor

Could you help me to write a good commit message for this patch, please?
I would appreciate if you could update the description with the summary of the changes done in this refactoring.

I edited the description above with my first run at it. Hows that work for you?

@bader
Copy link
Contributor

bader commented Apr 22, 2020

It works for me. Thank you.

@bader bader merged commit de1c363 into intel:sycl Apr 22, 2020
alexbatashev pushed a commit to alexbatashev/llvm that referenced this pull request Apr 29, 2020
…versioning

* origin/sycl:
  [XPTI][Framework] Reference implementation of the Xpti framework to be used with instrumentation in SYCL (intel#1557)
  [SYCL] Initial ABI checks implementation (intel#1528)
  [SYCL] Support connection with multiple plugins (intel#1490)
  [SYCL] Add a new header file with the reduction class definition (intel#1558)
  [SYCL] Add test for SYCL kernels with accessor and spec constant (intel#1536)
  [SYCL][CUDA] Move interop tests (intel#1570)
  [Driver][SYCL] Remove COFF object format designator for Windows device compiles (intel#1574)
  [SYCL] Fix conflicting visibility attributes (intel#1571)
  [SYCL][DOC] Update the SYCL Runtime Interface document with design details (intel#680)
  [SYCL] Improve image accessors support on a host device (intel#1502)
  [SYCL] Make queue's non-USM event ownership temporary (intel#1561)
  [SYCL] Added support of rounding modes for non-host devices (intel#1463)
  [SYCL] SemaSYCL significant refactoring (intel#1517)
  [SYCL] Support 0-dim accessor in handler::copy(accessor, accessor) (intel#1551)
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.

4 participants