[clang] [clang-sycl-linker] Make JIT/AOT temp files land relative to cwd with unique names (PR #224506)

[Wenju He via cfe-commits]

================
@@ -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