[NewOffloadModel] Add additional options for clang-sycl-linker by YixingZhang007 · Pull Request #21692 · intel/llvm

YixingZhang007 · 2026-04-07T12:43:36Z

This patch is part of the ongoing effort to migrate to clang-sycl-linker. It adds the support for new options required for clang-sycl-linker, where they will be used during the linking and backend compilation stages.
Specifically, the following changes are made:

New options supported by clang-sycl-linker are defined in SYCLLinkOpts.td.
In ClangLinkerWrapper.cpp, appendClangSYCLLinkerArgsis introduced to forward the required flags toclang-sycl-linkervia-XlinkerwhenUseClangSYCLLinkeris enabled.UseClangSYCLLinkeris a temporary guard that will be removed onceclang-sycl-linker` is fully supported.
Updated to process arguments passed to clang and forward any -Xlinker arguments to clang-sycl-linker in SPIRV.cpp.

…cl-linker

mdtoguchi · 2026-04-07T16:41:58Z

+      if (A->getOption().matches(options::OPT_Xlinker)) {
+        CmdArgs.push_back(A->getValue());
+      }
+    }


Why is this needed? I'm seeing values of -Xlinker already being passed as expected.

clang++ --sycl-link --target=spirv64 -### a.o -Xlinker -blah
Intel SYCL compiler development build based on:
clang version 23.0.0git (https://github.com/mdtoguchi/llvm accf054)
Target: spirv64
Thread model: posix
InstalledDir: /localdisk2/mtoguchi/github/llvm/build/bin
Build config: +assertions
"clang-sycl-linker" "a.o" "-blah" "-o" "a.out"

Thank you for catching this! You're right, the -xlinker option is already handled within AddLinkerInputs function. I've reverted this change :)

mdtoguchi · 2026-04-07T16:57:56Z

+  };
+  for (auto [Opt, Flag] : SimpleFlags)
+    if (Args.hasArg(Opt))
+      XLinker(Flag);


It looks like we have a bit of duplication of option names, etc, which would lead to a maintenance issue with any option name changes or even capturing new flags that need to be forwarded.

Leveraging the Args information would be beneficial here. A new 'Group' can be added for any of these options that need to be forwarded to the clang-sycl-linker. From there, check if an Arg is part of the group and then forward with render()

for (Arg *A : Args.filtered(options::OPT_sycl_Group)) A->render(Args, CmdArgs);

Hm I am not quiet sure about this because the flags passed to clang-linker-wrapper need to be handled / processed differently when they get passed to clang-sycl-linker (for example option passed into --device-libs= need to be joined by comma). In this case, there might need to be several groups created.

Sure - This was more of a comment for the general case where options can be directly mapped. Exceptions can be handled differently. Instead of creating a group, just a list of the OPT_ values that do map directly to do the checking, then passing the direct render. At least this way there are less strings to manage.

Ah, I see! I've created two lists, DirectOpts and ValueOpts, for options that are shared between clang-linker-wrapper and clang-sycl-linker. By calling A->getOption().getName().str(), we can generate the flag names dynamically instead of hardcoding strings, so we avoid maintaining a separate list of hardcoded strings. Please feel free to let me know if anything needed to be changed. Thank you! :)

elizabethandrews

I am not familiar with this and defer to @mdtoguchi for review and approval.

mdtoguchi · 2026-04-13T16:45:30Z

+
+def input_file_EQ : Joined<["--", "-"], "input-file=">,
+  Flags<[LinkerOnlyOption]>,
+  HelpText<"Input bitcode file for SYCL device linking">;


Given the text information here - how is this option different than using --bitcode-library? The name of -input-file makes it sound like you can pass any input file and clang-sycl-linker will just know what to do with the file and it not be of any type of file format, so the option name should be more descriptive.

Thanks for the suggestion. I have changed the option name to be input-bitcode-file= and add a more descriptive comment for both this option as well as --bitcode-library.

mdtoguchi · 2026-04-15T23:05:14Z

+  HelpText<"Output in the SYCLBIN binary format in the state specified by <arg> (input, object or executable)">;
+
+// Options to specify SYCL device kernel bitcode input files, extracted from offload binaries.
+def input_bitcode_file_EQ : Joined<["--", "-"], "input-bitcode-file=">,


How are --input-bitcode-file, --bitcode-library and --device-libs used? They all seem to imply the same things.

--bitcode-library and --device-libs look similar.
--input-bitcode-file looks different.

I think --input-bitcode-file is not necessary since currently the tool uses OPT_INPUT.

https://github.com/YixingZhang007/llvm/blob/283aab924a810c14d5d389941537f79aee24bad0/clang/tools/clang-sycl-linker/ClangSYCLLinker.cpp#L188

The --bitcode-library is the same as the --bitcode-library option being passed from clang to clang-linker-wrapper, and the --device-libs are the same as the sycl-device-libraries being passed from clang to clang-linker-wrapper.

--bitcode-library directly injects a raw bitcode file into the SYCL device link stage, filtered by target triple.
--device-libs injects SYCL runtime library files by filename, resolved from a search directory passed through --library-path=, extracting the correct target's binary from fat offload containers before linking.

Both feed the bitcode library to the same second llvm-link step, but --bitcode-library is a simple direct path while --device-libs adds a layer of directory resolution.
I will add comment for these two options to explain the details.

For --input-bitcode-file, I'm thinking of creating it to pass the device input files that are extracted from host fat binaries and converted from SPIR-V to LLVM IR using spirv-to-ir-wrapper. Thanks for the suggestion from Maksim, I agree that we can use the existing OPT_INPUT option and I will remove this --input-bitcode-file

The use of --sycl-device-libraries should go away. We have moved to linking in the device libraries at compile time and have stopped passing --sycl-device-libraries and --sycl-device-library-location to the clang-linker-wrapper.

maksimsab

Is it possible to add testing?

YixingZhang007 · 2026-04-16T19:55:49Z

Because I will be leaving this project soon and there is limited time I can work on this PR, I think it would be better to address some of the suggested changes in the comments in a future PR and keep the current PR with the feature we have right now. There are two changes that need to be made in future PRs:

Add a test to verify that options passed into clang-linker-wrapper are passed to clang-sycl-linker.
Remove --sycl-device-libraries and --sycl-device-library-location from clang-linker-wrapper, and also remove --device-libs and --library-path from clang-sycl-linker (we are currently still using these options in clang-sycl-linker).

@mdtoguchi @maksimsab Please feel free to let me know if this works, and I will note it in the Jira issue as well.

mdtoguchi · 2026-04-16T21:06:38Z

Because I will be leaving this project soon and there is limited time I can work on this PR, I think it would be better to address some of the suggested changes in the comments in a future PR and keep the current PR with the feature we have right now. There are two changes that need to be made in future PRs:

Add a test to verify that options passed into clang-linker-wrapper are passed to clang-sycl-linker.

Remove --sycl-device-libraries and --sycl-device-library-location from clang-linker-wrapper, and also remove --device-libs and --library-path from clang-sycl-linker (we are currently still using these options in clang-sycl-linker).

@mdtoguchi @maksimsab Please feel free to let me know if this works, and I will note it in the Jira issue as well.

Okay by me. One thing to note, however, is that --sycl-device-library-location is still being used for resolving some bitcode files that are added in the clang-linker-wrapper itself. When we move those into the driver --sycl-device-library-location can be cleaned out. --sycl-device-libraries should be OK to clean out now.

dm-vodopyanov changed the title ~~[NewOffloadModel] Add additional options for clang-sycl-sinker~~ [NewOffloadModel] Add additional options for clang-sycl-linker Apr 7, 2026

YixingZhang007 added the new-offload-model Enables testing with NewOffloadModel. label Apr 7, 2026

yixing.zhang added 5 commits April 7, 2026 16:26

add the initial draft

41b3690

add the change in clang-linker-wrapper for passing option to clang-sy…

f70c5c0

…cl-linker

code clean up

b29c590

code clean up

5456140

code clean up

81ce781

YixingZhang007 force-pushed the add_new_option_clang_sycl_linker branch from 4915195 to 81ce781 Compare April 7, 2026 14:29

yixing.zhang added 2 commits April 7, 2026 16:30

code clean up

fe65990

code clean up for device lib option

0c90903

YixingZhang007 marked this pull request as ready for review April 7, 2026 14:35

YixingZhang007 requested review from a team as code owners April 7, 2026 14:35

resolve clang format failure

0c8562b

mdtoguchi reviewed Apr 7, 2026

View reviewed changes

YixingZhang007 requested a review from maksimsab April 8, 2026 13:27

elizabethandrews reviewed Apr 10, 2026

View reviewed changes

resole mike comment 1/2

5121465

mdtoguchi reviewed Apr 13, 2026

View reviewed changes

yixing.zhang added 3 commits April 13, 2026 19:29

resolve comment

d497662

add detail description for input file bitcode

5fcc6aa

code clean up

2f75828

YixingZhang007 requested a review from mdtoguchi April 14, 2026 13:44

yixing.zhang added 3 commits April 14, 2026 15:47

resolve clang format failure

4138abc

resolve mike's comment

1f75532

code clean up

283aab9

mdtoguchi reviewed Apr 15, 2026

View reviewed changes

maksimsab requested changes Apr 16, 2026

View reviewed changes

yixing.zhang added 2 commits April 16, 2026 17:52

remove input file option and the device library option

8162341

revert the change of removing library_path_EQ and device_libs_EQ

1b7017b

YixingZhang007 requested a review from maksimsab April 16, 2026 23:17

srividya-sundaram mentioned this pull request May 7, 2026

[SYCL] Add option forwarding from clang-linker-wrapper tool to clang-sycl-linker #21958

Open

Conversation

YixingZhang007 commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

elizabethandrews left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

YixingZhang007 Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mdtoguchi Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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 Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maksimsab left a comment

Choose a reason for hiding this comment

Uh oh!

YixingZhang007 commented Apr 16, 2026

Uh oh!

mdtoguchi commented Apr 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

YixingZhang007 commented Apr 7, 2026 •

edited

Loading

YixingZhang007 Apr 13, 2026 •

edited

Loading

mdtoguchi Apr 15, 2026 •

edited

Loading

YixingZhang007 Apr 16, 2026 •

edited

Loading