Skip to content

Conversation

@frasercrmck
Copy link
Contributor

This removes the dependency on an external tool to build the SPIR-V files. It may be of interest to projects such as Mesa.

Note that the option is off by default as using the SPIR-V backend, at least on my machine, uses a lot of memory and the process is often killed in a parallelized build. It does complete, however.

Fixes #135327.

This removes the dependency on an external tool to build the SPIR-V
files. It may be of interest to projects such as Mesa.

Note that the option is off by default as using the SPIR-V backend, at
least on my machine, uses a *lot* of memory and the process is often
killed in a parallelized build. It does complete, however.

Fixes llvm#135327.
@frasercrmck frasercrmck requested review from nikic and wenju-he July 30, 2025 14:50
@frasercrmck frasercrmck added the libclc libclc OpenCL library label Jul 30, 2025
Copy link
Contributor

@nikic nikic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@nikic
Copy link
Contributor

nikic commented Jul 30, 2025

Note that the option is off by default as using the SPIR-V backend, at least on my machine, uses a lot of memory and the process is often killed in a parallelized build. It does complete, however.

I see the same behavior, goes up to something like 30GB. The input is not particularly large (just 300k lines of IR).

From a quick run through massif, it looks like MachineInstrs in SPIRVGlobalRegistry are the memory hog?

)
if ( LIBCLC_USE_SPIRV_BACKEND )
add_custom_command( OUTPUT ${libclc_builtins_lib}
COMMAND ${clang_exe} --target=${ARG_TRIPLE} -x ir -o ${libclc_builtins_lib} ${builtins_link_lib}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should -c be added to clang command line? It avoids spirv-link step.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question! I'm not sure, to be honest. I tried using -c and it generates a slightly larger file (6900 vs 6792). It seems to take a few fewer seconds to do so, which is an upside. I haven't looked into what exactly it's doing.

Copy link
Contributor

@wenju-he wenju-he Aug 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps spirv-link does optimization, but obviously there is only one file to link. LGTM as the final size is smaller, so this is not meant to be a blocker.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry, not meant to be

Copy link
Contributor

@wenju-he wenju-he left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@frasercrmck frasercrmck merged commit b0313ad into llvm:main Aug 1, 2025
11 checks passed
@frasercrmck frasercrmck deleted the libclc-spirv-backend branch August 1, 2025 08:48
@FireBurn
Copy link

FireBurn commented Oct 1, 2025

Can this be backported to 21?

@nikic
Copy link
Contributor

nikic commented Oct 1, 2025

I don't think it makes sense to backport this. At least at the time it landed it only worked in the sense of "does not crash during compilation". I'm not sure if the big compile-time and memory usage issue has been resolved since, or anyone has checked whether the produced SPIRV actually works.

@FireBurn
Copy link

FireBurn commented Oct 1, 2025

Yeah, it looks like at least 638383c is needed on 21 to make it work

Just that infact

@kwk
Copy link
Contributor

kwk commented Nov 25, 2025

Hi. When trying to build libclc using LIBCLC_USE_SPIRV_BACKEND=ON on a beefy machine I run into memory issues as can be seen in these screenshots:

Here we begin compiling a bc file:

image

Still compiling the same file, memory goes up to 62GB + 8GB of swap:

Screenshot From 2025-11-25 11-21-41

Here's the failing result:

image

The file being compiled at the time of high memory consumption is this:

> ls -hla /builddir/build/BUILD/llvm-22.0.0_pre20251106.g93ef57617d080f-build/llvm-project-93ef57617d080f6eac7a064e09f3e4145c334ae8/llvm/redhat-linux-build/tools/libclc/obj.libclc.dir/amdgcn--amdhsa/builtins.opt.amdgcn--amdhsa.bc
-rw-r--r--. 1 mockbuild mock 6.6M Nov 25 10:16 /builddir/build/BUILD/llvm-22.0.0_pre20251106.g93ef57617d080f-build/llvm-project-93ef57617d080f6eac7a064e09f3e4145c334ae8/llvm/redhat-linux-build/tools/libclc/obj.libclc.dir/amdgcn--amdhsa/builtins.opt.amdgcn--amdhsa.bc

The code I test with is from Nov. 6th 2025 93ef576. I try to build with a newer revision of LLVM but I think it is worth mentioning this.

@kwk
Copy link
Contributor

kwk commented Nov 25, 2025

Okay, I ran a test again with revision from 25th November 2025 (2f8e712).

Here's how I can reproduce it:

bash-5.3# cd /builddir/build/BUILD/llvm-22.0.0_pre20251125.g2f8e71287542a5-build/llvm-project-2f8e71287542a597be246d34699c93345d096f22/llvm/redhat-linux-build/tools/libclc
bash-5.3# /builddir/build/BUILD/llvm-22.0.0_pre20251125.g2f8e71287542a5-build/llvm-project-2f8e71287542a597be246d34699c93345d096f22/llvm/redhat-linux-build/bin/clang-22 --target=spirv64-- -x ir -o /builddir/build/BUILD/llvm-22.0.0_pre20251125.g2f8e71287542a5-build/llvm-project-2f8e71287542a597be246d34699c93345d096f22/llvm/redhat-linux-build/./bin/../lib/clang/22/lib/libclc/spirv64-mesa3d-.spv /builddir/build/BUILD/llvm-22.0.0_pre20251125.g2f8e71287542a5-build/llvm-project-2f8e71287542a597be246d34699c93345d096f22/llvm/redhat-linux-build/tools/libclc/obj.libclc.dir/spirv64-mesa3d-/builtins.link.spirv64-mesa3d-.bc
clang-22: error: unable to execute command: posix_spawn failed: No such file or directory
clang-22: error: spirv-link command failed with exit code 1 (use -v to see invocation)

Here're the bc file details:

bash-5.3# ls -lha /builddir/build/BUILD/llvm-22.0.0_pre20251125.g2f8e71287542a5-build/llvm-project-2f8e71287542a597be246d34699c93345d096f22/llvm/redhat-linux-build/tools/libclc/obj.libclc.dir/spirv64-mesa3d-/builtins.link.spirv64-mesa3d-.bc
-rw-r--r--. 1 mockbuild mock 2.3M Nov 25 10:52 /builddir/build/BUILD/llvm-22.0.0_pre20251125.g2f8e71287542a5-build/llvm-project-2f8e71287542a597be246d34699c93345d096f22/llvm/redhat-linux-build/tools/libclc/obj.libclc.dir/spirv64-mesa3d-/builtins.link.spirv64-mesa3d-.bc

But this time the memory consumption only jumped to 34GB and no swap. This is probably due to --with fastclang RPM option that I used to speed up the overall RPM compilation. The option will turn off building lldb, offload, mlir, flang, bolt, polly, and LTO.

Here's a screen shot right before the error (this time with -v):

Screenshot From 2025-11-25 12-30-53

And here's one screenshot after the error:

image

@frasercrmck
Copy link
Contributor Author

Hi! Yeah I saw the same thing when I was playing around with this (see the PR description). At the time I remember attributing it to the GlobalISel used by SPIR-V. I didn't have any further data points to see whether it was an issue specific to the SPIR-V backend or generally a GlobalISel problem. SPIR-V does custom things with book-keeping which might account for the memory usage.

I'm no longer working on this project, but I'd suggest seeing if other GlobalISel backends see a similar degradation in performance. If not, it's probably worth filing a ticket with the SPIR-V folks.

I don't have any good suggestions about how to work with what we've got. We could create smaller modules, or reduce parallelisation for the SPIR-V targets? Anything done would in all likelihood be a brittle workaround to the build system.

@kwk
Copy link
Contributor

kwk commented Nov 25, 2025

Thank you @frasercrmck for the feedback. I see what I can do. For now I just want to add two massif profiles that I created:

massif.out.zip

Here's one visualized:

image

From a quick run through massif, it looks like MachineInstrs in SPIRVGlobalRegistry are the memory hog?

@nikic, unfortunately I couldn't verify this with my abilities. Both profiles seem to have no notion of SPIRVGlobalRegistry. Maybe this is because I don't have debug symbols.

$ ms_print massif.out.15 | grep SPIRVGlobalRegistry
$ ms_print massif.out.17 | grep SPIRVGlobalRegistry

Update: When running valgrind with the default memcheck tool we saw leaks. I now try to build a version with the address sanitizer (that includes the leak sanitizer) to find out where the leaks are.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

libclc libclc OpenCL library

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use spirv backend in libclc

5 participants