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-PTX] Libclc binding for SYCL device #1914

Merged
merged 1 commit into from
Jun 24, 2020

Conversation

Naghasan
Copy link
Contributor

SYCL uses a custom mangling scheme (mangles target address space 0).
This patch adds a "binding" layer (sycldevice-binding.cpp).
The binding layer is compiled in sycl device mode which allow to generate
the expected mangling when the target address space is 0.

Signed-off-by: Victor Lomuller victor@codeplay.com

@Naghasan Naghasan requested a review from bader as a code owner June 17, 2020 15:27
@Naghasan
Copy link
Contributor Author

@bader This relates to one of the question I raised during the unstreaming call regarding the mangling approach (adding AS0 for SYCL device). This is kind of a workaround so that the lib binds correctly which what the sycl device compile generates.

@Naghasan Naghasan force-pushed the victor/spirv-ptx-sycl-binding branch 2 times, most recently from 0a4f83b to 6fa3c99 Compare June 17, 2020 16:10
@bader
Copy link
Contributor

bader commented Jun 18, 2020

@bader This relates to one of the question I raised during the unstreaming call regarding the mangling approach (adding AS0 for SYCL device). This is kind of a workaround so that the lib binds correctly which what the sycl device compile generates.

@Naghasan, please, take a look at this use case: https://github.com/bader/llvm/pull/18/files#diff-9cbf615457fd73dff7e9840ed855fa9aR82-R87. I think we need two separate instances of tmpl function template, where one of them works with a pointer to address space 4 and other one with a pointer to address space 0. Unmodified mangler emits one tmpl instance for both functions.

Do you have any ideas how we can handle this case w/o modifying the mangler?

@Naghasan
Copy link
Contributor Author

Naghasan commented Jun 18, 2020

https://github.com/bader/llvm/pull/18/files#diff-9cbf615457fd73dff7e9840ed855fa9aR82-R87

The link don't put me on the region you highlight.
Although I do understand the problem, if the address space qualifier is Default, it skips the address space mangling part (kind of logic). Hence the need to force to mangle the "AS0" part.

Do you have any ideas how we can handle this case w/o modifying the mangler?

Not much idea at the moment unfortunately. I tried a few things, but the ripple effect were quite large. Hence the workaround here.

bader
bader previously approved these changes Jun 18, 2020
libclc/CMakeLists.txt Show resolved Hide resolved
@Naghasan Naghasan force-pushed the victor/spirv-ptx-sycl-binding branch from 6fa3c99 to a308de9 Compare June 19, 2020 09:46
libclc/CMakeLists.txt Outdated Show resolved Hide resolved
@Naghasan
Copy link
Contributor Author

Do you have any ideas how we can handle this case w/o modifying the mangler?

There is one that I haven't tried yet: create an address space mapping specificaly for the mangling. We should perhaps discuss this in a specific issue.

SYCL uses a custom mangling scheme (mangles target address space 0).
This patch adds a "binding" layer (sycldevice-binding.cpp).
The binding layer is compiled in sycl device mode which allow to generate
the expected mangling when the target address space is 0.

Signed-off-by: Victor Lomuller <victor@codeplay.com>
@Naghasan Naghasan force-pushed the victor/spirv-ptx-sycl-binding branch from a308de9 to 65a4390 Compare June 19, 2020 16:46
@bader bader added cuda CUDA back-end libclc libclc project related issues labels Jun 23, 2020
@bader
Copy link
Contributor

bader commented Jun 23, 2020

LIT failures on CUDA most likely caused by #1919.
I'll re-run to confirm.

@bader bader merged commit 761b2ea into intel:sycl Jun 24, 2020
bader added a commit to bader/llvm that referenced this pull request Apr 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cuda CUDA back-end libclc libclc project related issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants