Skip to content

[SYCL] Fix builtins address space type #4275

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 5 commits into from
Aug 19, 2021
Merged

Conversation

npmiller
Copy link
Contributor

@npmiller npmiller commented Aug 6, 2021

This patch fixes the core/GroupAsyncCopy.cl and ocl/prefetch.cl lit
tests in libclc.

These started failing with the introduction of the SYCL address spaces
in #3634.

The issue is that the builtins are declared with the SYCL address spaces
in the tablegen so when used in an OpenCL setting it ends up with
address space mismatches between things like opencl_global and
sycl_global.

These two were the only tests affected because they're also the only
tested builtins that do not have generic address space variants in
tablegen, the other tests would just fall back on the generic address
space variants.

With this patch the builtins should automatically get the appropriate
version of the address space depending on the context.

This patch fixes the `core/GroupAsyncCopy.cl` and `ocl/prefetch.cl` lit
tests in `libclc`.

These started failing with the introduction of the SYCL address spaces
in intel#3634.

The issue is that the builtins are declared with the SYCL address spaces
in the tablegen so when used in an OpenCL setting it ends up with
address space mismatches between things like `opencl_global` and
`sycl_global`.

These two were the only tests affected because they're also the only
tested builtins that do not have generic address space variants in
tablegen, the other tests would just fall back on the generic address
space variants.

With this patch the builtins should automatically get the appropriate
version of the address space depending on the context.
Copy link
Contributor

@Naghasan Naghasan left a comment

Choose a reason for hiding this comment

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

LGTM.

Might be good to have the SPIRVBuiltins.td to use the opencl_* address space rather than the sycl_* ones now that the flip happens here as well. The reason is this would be a step toward allowing type definition sharing with OpenCLBuiltins.td.

@elizabethandrews
Copy link
Contributor

@premanandrao @AaronBallman @bader please take a look. I am not too familiar with address space handling.

@premanandrao
Copy link
Contributor

@premanandrao @AaronBallman @bader please take a look. I am not too familiar with address space handling.

It looks good to me. But I would like @bader to confirm.

Copy link
Contributor

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

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

Changes seem reasonable to me, but should we have test coverage within SYCL for the changes?

@npmiller
Copy link
Contributor Author

Changes seem reasonable to me, but should we have test coverage within SYCL for the changes?

Well this is exercised in check-libclc and I believe there are plans to run check-libclc as part of check-sycl.

Also this is not really a problem in SYCL, rather it's a problem when using SPIR-V builtins with -x cl which is why it only showed up in the libclc testing.

@bader bader requested review from Naghasan and AaronBallman August 17, 2021 10:13
@AaronBallman
Copy link
Contributor

Changes seem reasonable to me, but should we have test coverage within SYCL for the changes?

Well this is exercised in check-libclc and I believe there are plans to run check-libclc as part of check-sycl.

Also this is not really a problem in SYCL, rather it's a problem when using SPIR-V builtins with -x cl which is why it only showed up in the libclc testing.

Understood, but this is still a functional change to SYCL, so it should come with test coverage. Otherwise, we increase the maintenance burden for folks working in this repo because they can't run local tests when making changes, so we run the risk of accidentally regressing behavior (and hopefully catch it when running check-libclc as part of check-sycl from CI some day). Note that check-sycl is not where I'd want to see the test coverage anyway; the changes are to Clang, so I'm hoping to see check-clang coverage if possible.

@npmiller
Copy link
Contributor Author

Changes seem reasonable to me, but should we have test coverage within SYCL for the changes?

Well this is exercised in check-libclc and I believe there are plans to run check-libclc as part of check-sycl.
Also this is not really a problem in SYCL, rather it's a problem when using SPIR-V builtins with -x cl which is why it only showed up in the libclc testing.

Understood, but this is still a functional change to SYCL, so it should come with test coverage. Otherwise, we increase the maintenance burden for folks working in this repo because they can't run local tests when making changes, so we run the risk of accidentally regressing behavior (and hopefully catch it when running check-libclc as part of check-sycl from CI some day). Note that check-sycl is not where I'd want to see the test coverage anyway; the changes are to Clang, so I'm hoping to see check-clang coverage if possible.

Oh I see, that makes sense, I'll add some specific clang tests for this.

AaronBallman
AaronBallman previously approved these changes Aug 17, 2021
Copy link
Contributor

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

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

LGTM, thank you for the additional test coverage!

@npmiller
Copy link
Contributor Author

I've had to update the lit tests patterns for windows, and it also turns out that the microsoft mangler didn't know how to mangle SYCL address spaces, so I'm not sure how that worked before.

So I've also added a patch to the microsoft mangler to add the SYCL address spaces and hopefully that works, I don't have a windows build on hand to test that further but maybe we can see what the CI says before I set that up.

Copy link
Contributor

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

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

LGTM

@bader bader merged commit 1e3136e into intel:sycl Aug 19, 2021
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.

6 participants