[SYCL] SYCL 2020 exceptions support

[cperkinsintel]

All the new SYCL2020 constructors and support functions are now supported. To avoid breaking the API, the error_code is hidden behind the null terminator of the what exception message.

Also note, at this time I have not converted the existing exceptions that the runtime throws to be SYCL2020 exceptions.

[bader]

Could you clarify the use case when this function can be called for an exception from SYCL 1.2.1 source, please?
If it's possible, we can not use MMsg message string to store the error code.
Any SYCL 1.2.1 exception with message satisfying following limitations will be recognized as SYCL 2020 exception:

• message string length >= reserved_for_errorcode length
• \0 is located at length of reserved_for_errorcode before the end of the message string

According to my understanding both conditions above is better to replace with assertions.

[cperkinsintel]

In their simplest form the exceptions newly specified for SYCL 2020 introduce ABI/API breaking changes. The goal here is to support SYCL 2020 exceptions but preserving the structure of the SYCL 1.2.1 ones for compatibility. For example, if a shared library written with SYCL 1.2.1 throws an exception, it should function even if the app that catches it is using SYCL 2020 exceptions. I don't think we want to assert.

You are right, if a SYCL 1.2.1 exception happens to put a string terminator into the middle of the string at this exact position, then it would be mistakenly recognized as a SYCL 2020 exception. I originally had a 'SYCL' marker inserted to help with forward string scanning, but was asked to remove it. But if restored then we face another hypothetical: "What if a SYCL 1.2.1 exception inserts a null terminator AND the 'SYCL' marker?".

Ultimately, I doubt anyone is inserting null string terminators into their messages.

[cperkinsintel]

If we are hiding this data behind the terminator, there are three ways of finding it:

• forward scan for the terminator. Problem: std::string can contain null terminators.
• reverse scan for the terminator. Problem: the error_code will most certainly contain bytes of value 0
• locate by position, since the size of the error code is fixed.

The third one is what we are using now, it seems the safest and is simple. However, if we are worried about it, it might be slightly improved upon by using a multi-byte marker of some sort. For example: \0\0\0\0 or \0SYCL or a combination of both: \0S\0Y\0C\0L\0F\0T\0W

[bader]

I think this limitation is significant enough to be mentioned as a known issue in the documentation.

[cperkinsintel]

@bader - do you have a recommendation on where it should be documented, exactly? I was hoping to just add this note to one of the existing docs, but unsure which is the best fit. Maybe sycl/doc/FAQ.md ?

[bader]

https://github.com/intel/llvm/blob/sycl/sycl/doc/GetStartedGuide.md#known-issues-and-limitations is a good place to start.

[vladimirlaz]

Could you please add tests for new version of exceptions (in intel/llvm-test-suite). There are some usages in kernel_bundle for the new API: llvm/sycl/source/detail/kernel_bundle_impl.hpp

[cperkinsintel]

@vladimirlaz - The PR includes tests all the new SYCL 2020 constructors and functions to this PR. ( sycl/test/basic_tests/exceptions-SYCL-2020.cpp ) After it is merged, we can move them over to llvm-test-suite. Are there more tests that you want developed?

[vladimirlaz]

@vladimirlaz - The PR includes tests all the new SYCL 2020 constructors and functions to this PR. ( sycl/test/basic_tests/exceptions-SYCL-2020.cpp ) After it is merged, we can move them over to llvm-test-suite. Are there more tests that you want developed?

this covers mostly synchronous exceptions. It would be great to test also asynchronous exceptions.

[cperkinsintel]

@vladimirlaz You mean throw an exception such that it is caught in the asynchronous exception handler that we can pass to the queue? How would we go about doing that? Kernel code can't throw, so I'm not sure how to do that. I poked around a bit, but I don't see any way for a test to create a SYCL 2020 exception (or any exception, for that matter) that would get caught by the asynchronous error handler. But perhaps you meant something else?

[vladimirlaz]

@vladimirlaz You mean throw an exception such that it is caught in the asynchronous exception handler that we can pass to the queue? How would we go about doing that? Kernel code can't throw, so I'm not sure how to do that. I poked around a bit, but I don't see any way for a test to create a SYCL 2020 exception (or any exception, for that matter) that would get caught by the asynchronous error handler. But perhaps you meant something else?

I was under impression that kernel_bundle generates SYCL2020 exceptions in asynchronous mode. It is not the case. So the tests for async exceptions can be added later (when we have such SYCL2020 exceptions).