-
Notifications
You must be signed in to change notification settings - Fork 121
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
[DeviceASAN] Fix ASAN with kernel assert #2415
[DeviceASAN] Fix ASAN with kernel assert #2415
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Hi @oneapi-src/unified-runtime-maintain, please review and add this to 2025.1. |
There was a problem hiding this 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, but I do have a general comment - this looks like a pretty big change in logic, with the not instrumented kernels now executing more code that was previously short-circuited with if (not instrumented) return KernelLaunch(...)
. Which might be fine, but there's no explanation in the commit description.
Do you have SYCL tests that exercise this path with non-instrumented kernels?
Ok, I will add explanation.
Thanks for reminder, I enhanced the kernel-filter test. |
Hi @pbalcer, the commit description was updated. |
UR: oneapi-src/unified-runtime#2415 --------- Co-authored-by: Martin Morrison-Grant <martin.morrisongrant@codeplay.com>
[DeviceASAN] Fix ASAN with kernel assert
LLVM: intel/llvm#16256
Even when the kernel is not instrumented, we still need to execute the same routine just like instrumented kernel.
That's because some of arguments have been intercepted by the sanitizer layer and are no longer compatible with the native level zero's value. For example, membuffer.