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

[srividya-sundaram]

This is the first patch in a series that moves SYCL device code linking logic from clang-linker-wrapper into the clang-sycl-linker tool.
I’m continuing the work from where Yixing left off.

At the moment, the tests only verify that the options are forwarded to clang-linker-wrapper.
Tests validating clang-sycl-linker invocations will be added in subsequent PRs.

Added infrastructure from PR 21692 + tests for option forwarding.

[maksimsab]

More general comment.
I see that your PR targets 2 independent goals:

• Add option forwarding
• Remove deprecated device library options

In cases like that the suggested approach is:

The patch should:
* be an isolated change. Independent changes should be submitted as separate patches as this makes reviewing easier.

https://llvm.org/docs/Contributing.html#how-to-submit-a-patch

Please, use this approach in your patches.

[YuriPlyakhin]

could you please update title?

[YuriPlyakhin]

this test looks similiar to the one I see in community: https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/linker-wrapper.c

Other similar tests that are programming-model or target specific:

https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/linker-wrapper-hip-amdgcnspirv.c

https://github.com/llvm/llvm-project/blob/e721580311e3988e767ec3aaa06bce025f72ff7e/clang/test/Driver/hipspv-toolchain.hip#L55

Do you think it would be possible to add test like you wrote here to community first aligned with naming and style? (like linker-wrapper-sycl.cpp), and then add modifications in downstream on top of what is in upstream?

I want to minimize our back-and-forth between downstream and community and submit to community first if that makes sense.

[srividya-sundaram]

Do you think it would be possible to add test like you wrote here to community first aligned with naming and style? (like linker-wrapper-sycl.cpp), and then add modifications in downstream on top of what is in upstream?

--use-clang-sycl-linker is a temporary downstream-only transition flag and won't be upstreamed.
The test is specifically for --use-clang-sycl-linker's behavior (dispatching to clang -fsycl --sycl-link), so there's no meaningful upstream test to write at this point.
Once we complete the migration and remove --use-clang-sycl-linker, I can submit an upstream SYCL test for (CLW invoking clang + fsycl + --sycl-link) that aligns with community naming standards.

[YuriPlyakhin]

this ordering of the code is causing nativecpu to use clang-sycl-linker. Does this pass work? Are there any tests for this?
same question for nvptx pass.

[srividya-sundaram]

CSL only handles SPIR-V/SPIR64 targets currently.
NativeCPU and NVPTX are not supported targets and should be excluded from entering this path. I have updated the check to allow SPIR/SPIRV triples only.

[YuriPlyakhin]

are all options which we are forwarding to clang-sycl-linker supported by it?

[srividya-sundaram]

I have some questions regarding adding new option definitions in CSL.
My understanding is we analyze each option from the CLW usage perspective and evaluate if that functionality needs to be replicated inside CSL instead.

--sycl-dump-device-code= - Add new option to CSL (not map to --spirv-dump-device-code=, which is SPIR-V only and would miss AOT outputs)
--llvm-spirv-options= - Keep in ValueOpts; add option definition to CSL
--sycl-post-link-options= - Keep in ValueOpts; add option definition to CSL
--syclbin= - Remove from ValueOpts; CLW handles SYCLBIN packaging after CSL returns
--bitcode-library= - Remove from ValueOpts; SYCL device libs are now linked at compile time via -mlink-builtin-bitcode in the driver

Can you clarify if this is correct?

[YuriPlyakhin]

this pr needs some more work.