[SYCL] Deprecate fallback assertions

[steffenlarsen]

This commit deprecates (and removes under preview flag) the fallback assertion implementation for SYCL kernels. The expected behavior after this is that backends that do not support native asserts, as reported through the ext_oneapi_native_assert aspect, will ignore assertions in kernel code.

This commit also makes the L0 adapter report support for native assert, as it was incorrectly reporting false before.

[npmiller]

I believe these two tests also rely on the fallback asserts:

• https://github.com/intel/llvm/blob/sycl/sycl/test-e2e/DiscardEvents/discard_events_using_assert.cpp
• https://github.com/intel/llvm/blob/sycl/sycl/test-e2e/DiscardEvents/discard_events_using_assert_ndebug.cpp

Or at least they used to, I'm not sure the current checks represent that intent, and they never had the macros defined. But you can see the comment for the cuda/hip unsupported. And fallback is really the only case that would make sense to test for discard events with assert since it adds extra commands that might add/use events. I've been meaning to dig further into them to re-enable them for CUDA and HIP, but if we're dropping fallback we might be able to just delete these eventually.

[gmlueck]

What is our plan for the assert feature once the environment variable is removed? Will assert statements simply be silently ignored if they appear in a kernel that is submitted to a device without native support? If that is the case, I think we need an update to the sycl_ext_oneapi_assert specification.

Or, will assert be treated like other device-optional features, and the implementation will throw an exception if the device does not support it? In this case, we would also need an update to sycl_ext_oneapi_assert.

[jbrodman]

I believe these two tests also rely on the fallback asserts:

• https://github.com/intel/llvm/blob/sycl/sycl/test-e2e/DiscardEvents/discard_events_using_assert.cpp
• https://github.com/intel/llvm/blob/sycl/sycl/test-e2e/DiscardEvents/discard_events_using_assert_ndebug.cpp

Or at least they used to, I'm not sure the current checks represent that intent, and they never had the macros defined. But you can see the comment for the cuda/hip unsupported. And fallback is really the only case that would make sense to test for discard events with assert since it adds extra commands that might add/use events. I've been meaning to dig further into them to re-enable them for CUDA and HIP, but if we're dropping fallback we might be able to just delete these eventually.

We'd ultimately like to get rid of DiscardEvents too...

[steffenlarsen]

What is our plan for the assert feature once the environment variable is removed? Will assert statements simply be silently ignored if they appear in a kernel that is submitted to a device without native support? If that is the case, I think we need an update to the sycl_ext_oneapi_assert specification.

This seems like the safest solution to me, as it means users can still run their kernels on devices where they would run before, even if we can't do the asserts in there for them. I've updated the extension.

[steffenlarsen]

It appears that L0 assertions don't print and abort at synchronization points, but instead does so at the end of the application. This has been reported internally.

[gmlueck]

It appears that L0 assertions don't print and abort at synchronization points, but instead does so at the end of the application. This has been reported internally.

This seems like it could be a serious bug. What happens if the application crashes and terminates abnormally? Does Level Zero print the assertion even when the application terminates abnormally like this? What if the application hangs, and the user terminates it via CTRL-C? I would expect many failed assertion checks to result in either a crash or a hung application. If the assertion is not printed in either of these cases, it seems pretty limited.

[steffenlarsen]

This seems like it could be a serious bug. What happens if the application crashes and terminates abnormally? Does Level Zero print the assertion even when the application terminates abnormally like this? What if the application hangs, and the user terminates it via CTRL-C? I would expect many failed assertion checks to result in either a crash or a hung application. If the assertion is not printed in either of these cases, it seems pretty limited.

I absolutely agree. Even if there is some guarantee that it is printed by the end of the program, if the user cannot rely on it failing at the point of synchronization, it can be hard to track failures and users may want to rely on the abort happening before they continue on with the following tasks.

[jinge90]

Hi, @steffenlarsen
I created a PR #18089 to remove unused fallback assert implementation in libdevice previously, I think it can be merged into your current PR if we are going to deprecate fallback assert. Do you have any objection and concern? If no, I can add it to your current PR.
Thanks very much.

[steffenlarsen]

Hi, @steffenlarsen I created a PR #18089 to remove unused fallback assert implementation in libdevice previously, I think it can be merged into your current PR if we are going to deprecate fallback assert. Do you have any objection and concern? If no, I can add it to your current PR. Thanks very much.

Thank you, @jinge90 ! This patch should not change the behavior without the preview flag being set. Can we integrate your changes in the same way?

[jinge90]

Hi, @steffenlarsen I created a PR #18089 to remove unused fallback assert implementation in libdevice previously, I think it can be merged into your current PR if we are going to deprecate fallback assert. Do you have any objection and concern? If no, I can add it to your current PR. Thanks very much.

Thank you, @jinge90 ! This patch should not change the behavior without the preview flag being set. Can we integrate your changes in the same way?

Hi, @steffenlarsen
It should be doable, we can create a new libsycl-crt-previw.o which cleans up all fallback assert related code and links it with user's device code when -fpreview-breaking-changes is applied. If the option is not applied, we just link the original libsycl-crt.o, I will take a look at this later.
Thanks very much.

[steffenlarsen]

Hi, @steffenlarsen It should be doable, we can create a new libsycl-crt-previw.o which cleans up all fallback assert related code and links it with user's device code when -fpreview-breaking-changes is applied. If the option is not applied, we just link the original libsycl-crt.o, I will take a look at this later. Thanks very much.

If it isn't too much work, I don't mind doing it as part of this, though alternatively we can do it in a separate patch and just let the patch sit there until the breaking window opens. That way we won't need to make some preview work-around for now.

[jinge90]

Hi, @steffenlarsen It should be doable, we can create a new libsycl-crt-previw.o which cleans up all fallback assert related code and links it with user's device code when -fpreview-breaking-changes is applied. If the option is not applied, we just link the original libsycl-crt.o, I will take a look at this later. Thanks very much.

If it isn't too much work, I don't mind doing it as part of this, though alternatively we can do it in a separate patch and just let the patch sit there until the breaking window opens. That way we won't need to make some preview work-around for now.

Hi, @steffenlarsen
So I can continue to do this in #18089 and wait for the breaking windows opens.
When you plan to land current PR, please ping me to also land the libdevice part after current PR is merged. Is it OK for you?
Thanks very much.

[jinge90]

Hi, @steffenlarsen
I created a new PR: #18376 including driver change.
A new version of libsycl-fallback-cassert-preview is created removing all legacy fallback assert impl, this lib will be linked with user's device code only when -fpreview-breaking-changes. Please ping me when you plan to land your PR.
Thanks very much.

[aelovikov-intel]

nit: For if/else cases it's more readable to use #ifdef <preview>/#else/#endif, IMO.