[SYCL] Added changes to support multiple archs in command line - #22945
Open
bviyer wants to merge 1 commit into
Open
[SYCL] Added changes to support multiple archs in command line#22945bviyer wants to merge 1 commit into
bviyer wants to merge 1 commit into
Conversation
bviyer
changed the title
bader
reviewed
Aug 14, 2026
Comment on lines
+2738
to
+2739
| // Value is space-joined; a leading "-device <arch>" routes it to | ||
| // that arch only. No -device prefix -> apply to every arch. |
Contributor
There was a problem hiding this comment.
ocloc doesn't work like that.
ocloc -device X -A -device Y -B - you assume ocloc will apply -A option to the compilation for device X and -B to the compilation for device Y. In fact, -A -B is applied to both compilations.
Contributor
There was a problem hiding this comment.
There is the -device_options option that may do what you want:
-device_options <device_type> <options> Optional OpenCL C compilation options
as defined by OpenCL specification - specific to a single target device.
Multiple product acronyms may be provided - separated by commas.
<device_type> can be product acronym or version passed in -device i.e. dg1 or 12.10.0
I didn't review the PR yet so maybe it doesn't, I just saw Alexey's comment.
mdtoguchi
reviewed
Aug 14, 2026
Comment on lines
+12349
to
+12353
| for (const char *T : BuildArgs) { | ||
| if (!Joined.empty()) | ||
| Joined += ' '; | ||
| Joined += T; | ||
| } |
Contributor
There was a problem hiding this comment.
The dd9abc1 change purposefully tokenizes the options to be passed to the clang-linker-wrapper. We seem to have effectively lost this behavior. Is there a reason why?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The clang-linker-wrapper --device-compiler=/--device-linker= channel did not distinguish between architectures sharing the same triple, so with
-fsycl-targets=spir64_gen,intel_gpu_sklplus per-target-Xsycl-target-backend, all options were emitted under a singlespir64_gen-unknown-unknownentry and per-arch tokens leaked across ocloc invocations (e.g. skl's options ended up on the pvc call and vice versa). The driver now emits one --device-compiler/--device-linker per (triple, arch) with tokens joined into a single value; gen entries carry a leading "-device " that the wrapper uses to route each value to the matching ocloc call, while values without "-device" (or from non-gen triples) still apply to every arch of the triple. This feature affects the new-offload-model only.