================
@@ -47,8 +47,8 @@
; SPLIT-SRC-NEXT: sycl-module-split: input: [[LLVMLINKOUT]].bc, mode:
translation_unit
; SPLIT-SRC-NEXT: [[S0:.*]].bc [kernel_b kernel_c ]
; SPLIT-SRC-NEXT: [[S1:.*]].bc [kernel_a ]
-; SPLIT-SRC-NEXT: LLVM backend: input: [[S0]].bc, output: {{.*}}_0.spv
-; SPLIT-SRC-NEXT: LLVM backend: input: [[S1]].bc, output: {{.*}}_1.spv
+; SPLIT-SRC-NEXT: LLVM backend: input: [[S0]].bc, output: {{.*}}_0{{.*}}.spv
+; SPLIT-SRC-NEXT: LLVM backend: input: [[S1]].bc, output: {{.*}}_1{{.*}}.spv
----------------
wenju-he wrote:
> One thing I’m curious about is whether that split index is guaranteed to
> remain stable for a given kernel across different invocations, or whether it
> can change depending on module/symbol ordering.
Thanks, that is a great insight.
claude suggests the split index is stable if following conditions are met:
1. Same set of input device bitcode files — no TU change
2. Same order of those input files on the clang-sycl-linker/driver command line
— determined by the build system's link-line generation
3. Same function order within each input TU's bitcode (essentially no front-end
or middle-end optimization order change)
4. Same IRSplitMode (kernel vs link_unit/TU) and same -fsycl-... categorization
inputs — since the category key is either the kernel name or the sycl-module-id
attribute value
5. Same entry-point set/attributes — e.g. EmitOnlyKernelsAsEntryPoints flag
unchanged
6. No archive member resolution difference (if inputs include archives)
The scenario that matters most is debugging inside clang-sycl-linker itself:
investigating a specific kernel's AOT/native-compile output while the input
bitcode (from middle-end) are fixed. In that scenario, 1/2/3/5/6 are satisfied
in general.
The index is only guaranteed stable for that fixed-input debugging workflow,
and in practice tends to hold for frontend/middle-end debugging too, since a
typical source/optimization change affects a kernel's body, not its position in
the module's function list.
https://github.com/llvm/llvm-project/pull/224506
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
