[SYCL] Tests for Level Zero linker flags #713
Conversation
The Level Zero backend never supported linker options, but it previously ignored them silently. The backend now raises an error if a request to link kernel code specifies any linker options. Add two new tests to verify this behavior. One test exercises the deprecated `program` API. The other exercises the new `kernel_bundle` API. The test using the `kernel_bundle` API is currently disabled (see the comments in the test for why). Also mark two existing tests as UNSUPPORTED on Level Zero. These tests were incorrectly passing OpenCL linker flags to the Level Zero backend. This used to work when the backend silently ignored the flags, but it now raises an error.
| @@ -3,8 +3,10 @@ | |||
| // RUN: %CPU_RUN_PLACEHOLDER %t.out | |||
| // RUN: %GPU_RUN_PLACEHOLDER %t.out | |||
| // RUN: %ACC_RUN_PLACEHOLDER %t.out | |||
| // XFAIL: cuda || hip | |||
| // XFAIL: ze_debug-1,ze_debug4 | |||
There was a problem hiding this comment.
@bso-intel: I saw that you recently added the XFAIL for "ze_debug". I assume it makes sense to remove this now because this test is now unsupported on Level Zero. Agree?
There was a problem hiding this comment.
Yes, I am okay to remove those XFAIL lines as long as Sergey agrees with // UNSUPPORTED: level_zero
| // This test is disabled because the runtime does not currently pass linker | ||
| // flags from SYCL_PROGRAM_LINK_OPTIONS when the program calls "sycl::link()". | ||
| // This seems like a bug since the runtime passes linker flags from that | ||
| // environment variable in other cases when it links device code. |
There was a problem hiding this comment.
@smaslov-intel: Do you agree that the behavior I describe above is a bug? If so, I'll create a bug report.
There was a problem hiding this comment.
I am not sure, the SYCL_PROGRAM_LINK_OPTIONS doc says "String of valid OpenCL link options", so it sounds like OpenCL specific. Also, given that Level-Zero doesn't support any linking options, why would we have an option to pass any?
There was a problem hiding this comment.
The handling for SYCL_PROGRAM_LINK_OPTIONS is done in the generic part of the DPC++ runtime. Currently, it only uses this envvar when a module is compiled in order to submit it to a device. In that case, the runtime passes the SYCL_PROGRAM_LINK_OPTIONS to piProgramLink regardless of the backend. Therefore, I think the intent of this envvar is that it can be used to pass options to the linker for any backend, not just for OpenCL.
The handling for sycl::link() is also in the generic part of the library. For some reason, that code does not use options from SYCL_PROGRAM_LINK_OPTIONS for any backend.
There was a problem hiding this comment.
I am OK making SYCL_PROGRAM_LINK_OPTIONS to be backend-agnostic (need to fix doc then).
There was a problem hiding this comment.
I created a bug report, which also captures the doc issue.
There was a problem hiding this comment.
I got feedback that I should pass the linker options via -Xsycl-target-linker instead of using SYCL_PROGRAM_LINK_OPTIONS . I modified the test to use that option, but it still fails. Therefore, this test is still disabled. I entered a new bug report to capture this issue.
There was a problem hiding this comment.
@smaslov-intel said:
Why is the test still disabled?
I assume you are asking about the "level-zero-link-flags.cpp" test? If so, my comment above is the answer.
Rewrite this test to pass the online linker options via "-Xsycl-target-linker" rather than SYCL_PROGRAM_LINK_OPTIONS. However, it still fails because the runtime still does not pass them to the "sycl::link()" call.
|
@smaslov-intel: Can you re-approve. I dismissed your approval when I updated a comment. The failures in CI should not hold up merging this PR. This failure is expected:
That test requires the matching PR intel/llvm#5268 to be merged. I verified that it does pass when I ran the This failure seems unrelated and seems to be a sporadically failing test:
Since this PR to the test suite did not change that test, I do not see how it could cause this failure. I tried running that test on the Linux test system "scsel-cfl-12.sc.intel.com". It did not fail for me after 100 iterations. |
The Level Zero backend never supported linker options, but it previously ignored them silently. The backend now raises an error if a request to link kernel code specifies any linker options. Add two new tests to verify this behavior. One test exercises the deprecated program API. The other exercises the new kernel_bundle API. The test using the kernel_bundle API is currently disabled (see the comments in the test for why). Also mark two existing tests as UNSUPPORTED on Level Zero. These tests were incorrectly passing OpenCL linker flags to the Level Zero backend. This used to work when the backend silently ignored the flags, but it now raises an error.
The Level Zero backend never supported linker options, but it previously ignored them silently. The backend now raises an error if a request to link kernel code specifies any linker options. Add two new tests to verify this behavior. One test exercises the deprecated program API. The other exercises the new kernel_bundle API. The test using the kernel_bundle API is currently disabled (see the comments in the test for why). Also mark two existing tests as UNSUPPORTED on Level Zero. These tests were incorrectly passing OpenCL linker flags to the Level Zero backend. This used to work when the backend silently ignored the flags, but it now raises an error.
The Level Zero backend never supported linker options, but it previously ignored them silently. The backend now raises an error if a request to link kernel code specifies any linker options. Add two new tests to verify this behavior. One test exercises the deprecated program API. The other exercises the new kernel_bundle API. The test using the kernel_bundle API is currently disabled (see the comments in the test for why). Also mark two existing tests as UNSUPPORTED on Level Zero. These tests were incorrectly passing OpenCL linker flags to the Level Zero backend. This used to work when the backend silently ignored the flags, but it now raises an error.
The Level Zero backend never supported linker options, but it
previously ignored them silently. The backend now raises an error if a
request to link kernel code specifies any linker options.
Add two new tests to verify this behavior. One test exercises the
deprecated
programAPI. The other exercises the newkernel_bundleAPI. The test using the
kernel_bundleAPI is currently disabled (seethe comments in the test for why).
Also mark two existing tests as UNSUPPORTED on Level Zero. These tests
were incorrectly passing OpenCL linker flags to the Level Zero backend.
This used to work when the backend silently ignored the flags, but it
now raises an error.
This is the test case for intel/llvm#5268