[SYCL][NewOffloadModel] Update SYCL device library generation for new offloading model #20512

YixingZhang007 · 2025-10-30T04:33:47Z

This pull request refactors the SYCL device library build and end-to-end tests to support the new offloading model, while maintaining backward compatibility for the old offloading model, with the following key changes.

The default device library (such as libsycl-itt-compiler-wrappers.o) is now compiled using the new offloading model, and the library ending with .new.o (such as libsycl-itt-compiler-wrappers.new.o) has been renamed to .old.o (such as libsycl-itt-compiler-wrappers.old.o), representing builds with the old offloading model. These changes are made in libdevice/cmake/modules/SYCLLibdevice.cmake.
The end-to-end tests in sycl/test-e2e/Config/kernel_from_file.cpp and sycl/test-e2e/SeparateCompile/test.cpp have been updated. The tests now validate both the new offloading model, and the backward compatibility for the old model (using clang-offload-bundler to extract device code from libraries).

YixingZhang007 · 2025-11-02T20:26:51Z

The modifications to set the new offloading model as default in this PR were directly copied from (#15121). These changes will be removed once CI confirms there are no regressions.

sarnex

thanks for the PR! one higher level comment below

sarnex · 2025-11-05T16:08:46Z

libdevice/cmake/modules/SYCLLibdevice.cmake

 set(bc_device_compile_opts -fsycl-device-only -fsycl-device-obj=llvmir)
-set(obj-new-offload_device_compile_opts -fsycl -c --offload-new-driver
+set(obj-old-offload_device_compile_opts -fsycl -c ${sycl_targets_opt} --no-offload-new-driver)
+set(obj_device_compile_opts -fsycl -c --offload-new-driver


my worry here is that it seems this PR enables the new offload model by default for some but not all compilation modes, and since we are setting the default device library files to be the new offloading model (since we pass --offload-new-driver), i am not sure of those compilation modes using the old offload model will be able to use libdevice. the new offload model supports using old libdevice files, but i had to explicitly implement that to get it working and i don't think anyone did the opposite case since it wasn't expected to be be needed, but it's possible it works automagically. can you make sure the cases using the old offload model still work?

Thank you for raising this concern! I tried compiling a few SYCL E2E tests using the old offload model (by passing --no-offload-new-driver to clang++). The compilation appears to work correctly. For the old offload model, I found that llvm-link is called on libsycl-xxx.bc, whereas in the new offload model, libsycl-xxx.o is linked via the clang-linker-wrapper.
To further verify, I will remove the changes in this PR that enable the new offloading model by default and rerun the tests to see if any failures will occur in CI.

Sounds good, thanks!

Is it necessary to enable new offload model by default for some compilation modes to resolve the original problem that PR is trying to solve?

…pass as well

YuriPlyakhin

It seems the change is causing CI to fail. Could you please fix CI?

…ne.txt

YuriPlyakhin · 2025-11-05T21:18:30Z

clang/lib/Driver/ToolChains/SYCL.cpp

  if (IsNewOffload)
    // For new offload model, we use packaged .bc files.
-    LibSuffix = IsWindowsMSVCEnv ? ".new.obj" : ".new.o";
+    LibSuffix = IsWindowsMSVCEnv ? ".obj" : ".o";


so, before this PR, old offloading model used name.ext library name pattern and new offloading model used name.new.ext library name pattern.
After the change as far as I can see both old and new offloading model use name.ext library.
Or what am I missing?

Thank you for pointing this out! Yes, you are right that before this PR, the old offloading model used name.ext and the new offloading model used name.new.ext. Currently, name.ext is built with the old offloading model and name.new.ext is built with the new offloading model. However, if we enable the new offloading model by default in the future, both name.ext and name.new.ext will be built with the new offloading model.

In this PR, we update name.ext to be built with the new offloading model, and we introduce name.old.ext which will be built with the old offloading model. As we can see from the testing so far, when we are compiling tests with the old offloading model and linking the name.ext (which is built with the new offloading model), the tests are working fine. However, we still want to keep name.old.ext in case users still want to interact with the old offloading model, such as in some of the tests where they want to extract the device code from the fat object file, which is only supported for the object file built with the old offloading model.

So, why not keep the names as is, and when we enable new offloading model by default, just stop using name.new.ext?

YuriPlyakhin · 2025-11-05T21:28:35Z

libdevice/test/sycl_noinline.txt

 RUN: clang-offload-bundler -type=o -unbundle \
 RUN:     -targets=sycl-spir64-unknown-unknown \
-RUN:     -input=%libsycldevice_obj_dir/libsycl-fallback-cassert.o -output=%t.bc
+RUN:     -input=%libsycldevice_obj_dir/libsycl-fallback-cassert.old.o -output=%t.bc


Is it necessary to do this renaming now? why not keep default offloading model used now without additional suffixes and new offloading model to keep using new suffixes?

YuriPlyakhin · 2025-11-05T21:30:18Z

sycl/test-e2e/Config/kernel_from_file.cpp

-// >> ---- unbundle compiler wrapper and asan device objects
-// RUN: clang-offload-bundler -type=o -targets=sycl-spir64-unknown-unknown -input=%sycl_static_libs_dir/libsycl-itt-compiler-wrappers%obj_ext -output=%t_compiler_wrappers.bc -unbundle
-// RUN: %if linux %{ clang-offload-bundler -type=o -targets=sycl-spir64-unknown-unknown -input=%sycl_static_libs_dir/libsycl-asan%obj_ext -output=%t_asan.bc -unbundle %}
+


I think we need to keep existing E2E tests as is, without changes to make sure backward compatibility.
And if you want to add new tests for new offloading model, please add them to https://github.com/intel/llvm/tree/sycl/sycl/test-e2e/NewOffloadDriver

srividya-sundaram · 2025-11-05T21:32:59Z

clang/lib/Driver/ToolChains/SYCL.cpp

  bool IsNewOffload = C.getDriver().getUseNewOffloadingDriver();
  StringRef LibSuffix = ".bc";
  if (IsNewOffload)
    // For new offload model, we use packaged .bc files.


Please update the comment since we now use object files and not bitcode files.

srividya-sundaram · 2025-11-05T21:33:20Z

clang/lib/Driver/ToolChains/SYCL.cpp

  bool IsNewOffload = C.getDriver().getUseNewOffloadingDriver();
  StringRef LibSuffix = ".bc";
  if (IsNewOffload)
    // For new offload model, we use packaged .bc files.


Same comment as above.

YixingZhang007 · 2025-11-05T23:04:25Z

After discussion with @YuriPlyakhin and @sarnex, we have decided that we will not change the naming of the device library (from 'name.new.o' to 'name.old.o') in this PR. Instead, we will add --no-new-offload-model for building the default library ('name.o') such that the default device library will be built with the old offloading model for now.

The renaming (from 'name.new.o' to 'name.old.o') and setting the default device library to be built with the new offloading model will happen at the same time when we enable the new offloading model to be the default in the future. There should also be no change made to the tests sycl/test-e2e/Config/kernel_from_file.cpp and sycl/test-e2e/SeparateCompile/test.cpp at this time because we are still keeping the default device library ('name.o') to be built with the old offloading model.

This PR will be closed and a new PR will be opened soon with the changes discussed above.

YixingZhang007 requested review from a team as code owners October 30, 2025 04:33

YixingZhang007 requested a review from againull October 30, 2025 04:33

YixingZhang007 marked this pull request as draft October 30, 2025 04:33

YixingZhang007 had a problem deploying to WindowsCILock October 30, 2025 04:34 — with GitHub Actions Failure

YixingZhang007 changed the title ~~[SYCL][NewOffloadModel] Remove Clang Offload Bundler testing to fix E2E test failures with new offloading model~~ [SYCL][NewOffloadModel] Remove Clang Offload Bundler testing to fix E2E test failures Oct 30, 2025

YixingZhang007 changed the title ~~[SYCL][NewOffloadModel] Remove Clang Offload Bundler testing to fix E2E test failures~~ [SYCL][NewOffloadModel] Remove Clang Offload Bundler testing for new offloading model Oct 30, 2025

YixingZhang007 had a problem deploying to WindowsCILock October 30, 2025 05:09 — with GitHub Actions Failure

YixingZhang007 had a problem deploying to WindowsCILock November 2, 2025 16:01 — with GitHub Actions Failure

YixingZhang007 had a problem deploying to WindowsCILock November 2, 2025 16:29 — with GitHub Actions Failure

YixingZhang007 had a problem deploying to WindowsCILock November 2, 2025 18:20 — with GitHub Actions Failure

YixingZhang007 changed the title ~~[SYCL][NewOffloadModel] Remove Clang Offload Bundler testing for new offloading model~~ [SYCL][NewOffloadModel] Update SYCLLibdevice generation for new offloading model Nov 2, 2025

YixingZhang007 changed the title ~~[SYCL][NewOffloadModel] Update SYCLLibdevice generation for new offloading model~~ [SYCL][NewOffloadModel] Update SYCL device library generation for new offloading model Nov 2, 2025

YixingZhang007 had a problem deploying to WindowsCILock November 2, 2025 18:49 — with GitHub Actions Failure

YixingZhang007 had a problem deploying to WindowsCILock November 2, 2025 19:59 — with GitHub Actions Failure

YixingZhang007 marked this pull request as ready for review November 2, 2025 20:31

YixingZhang007 had a problem deploying to WindowsCILock November 2, 2025 20:42 — with GitHub Actions Failure

YixingZhang007 marked this pull request as draft November 2, 2025 23:32

YixingZhang007 had a problem deploying to WindowsCILock November 3, 2025 01:55 — with GitHub Actions Failure

YixingZhang007 force-pushed the offload_cant_find_bundle_issue branch from 8257fbd to 76e101f Compare November 3, 2025 02:24

YixingZhang007 had a problem deploying to WindowsCILock November 3, 2025 02:24 — with GitHub Actions Failure

YixingZhang007 had a problem deploying to WindowsCILock November 3, 2025 02:55 — with GitHub Actions Failure

YixingZhang007 marked this pull request as ready for review November 5, 2025 13:55

sarnex reviewed Nov 5, 2025

View reviewed changes

YixingZhang007 added 8 commits November 5, 2025 09:32

Add nick's changes=

7d6b80f

modify the commands in kernal_from_file.cpp and this test is now passing

67f0939

clean up the test command in kernel_from_file.cpp

dca2051

change the test command for SeperateCompiler/test.cpp, now this test …

94d03ca

…pass as well

add support for backward compatibility

324d02a

update the test to test backward compatibility

b1a8f8d

code clean up and resolve CI failure

9dfd1af

revert the changes for enabling new offloading model by default

89b35d5

YixingZhang007 force-pushed the offload_cant_find_bundle_issue branch from 76e101f to 89b35d5 Compare November 5, 2025 18:37

YixingZhang007 had a problem deploying to WindowsCILock November 5, 2025 18:37 — with GitHub Actions Failure

YixingZhang007 requested review from YuriPlyakhin, aelovikov-intel, maarquitos14, maksimsab and srividya-sundaram November 5, 2025 18:49

YuriPlyakhin reviewed Nov 5, 2025

View reviewed changes

YixingZhang007 temporarily deployed to WindowsCILock November 5, 2025 19:25 — with GitHub Actions Inactive

resolve the CI failure by updating the .o to be .old.o in sycl_noinli…

ff7ea74

…ne.txt

YixingZhang007 had a problem deploying to WindowsCILock November 5, 2025 20:49 — with GitHub Actions Failure

YuriPlyakhin reviewed Nov 5, 2025

View reviewed changes

YixingZhang007 temporarily deployed to WindowsCILock November 5, 2025 21:23 — with GitHub Actions Inactive

YuriPlyakhin reviewed Nov 5, 2025

View reviewed changes

srividya-sundaram reviewed Nov 5, 2025

View reviewed changes

YixingZhang007 closed this Nov 5, 2025

[SYCL][NewOffloadModel] Update SYCL device library generation for new offloading model #20512

[SYCL][NewOffloadModel] Update SYCL device library generation for new offloading model #20512

Uh oh!

Conversation

YixingZhang007 commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

YixingZhang007 commented Nov 2, 2025

Uh oh!

sarnex left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

YuriPlyakhin left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

YixingZhang007 commented Nov 5, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

YixingZhang007 commented Oct 30, 2025 •

edited

Loading