Skip to content

[LLVM] Fix llvm-gpu-loader use in standalone #132664

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

RossComputerGuy
Copy link
Member

Fixes the standalone builds of LLVM itself. In nixpkgs, we create a trimmed down copy of the LLVM monorepo for compatibility with older LLVM releases. We don't include libc in this copy which causes the llvm-libc-common-utilities target to not be defined. This causes llvm-gpu-loader to try linking to llvm-libc-common-utilities but fails due to the target not existing.

@RossComputerGuy RossComputerGuy requested a review from jhuber6 March 24, 2025 04:00
@llvmbot llvmbot added the cmake Build system in general and CMake in particular label Mar 24, 2025
Copy link
Contributor

@jhuber6 jhuber6 left a comment

Choose a reason for hiding this comment

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

So this is an intentional decision by nix to not provide the whole tree? If that's the case then we don't need to modify the CMake because it's changing the monorepo layout which is something we can't control. I feel like this is up to nix to fix. Does passing -DLLVM_TOOL_LLVM_GPU_LOADER_BUILD=OFF work?

@RossComputerGuy
Copy link
Member Author

So this is an intentional decision by nix to not provide the whole tree?

Yeah, we just provided a minimal source tree.

Does passing -DLLVM_TOOL_LLVM_GPU_LOADER_BUILD=OFF work?

Yes but this PR simplifies things by not having to manually provide it and run into the linker error.

@jhuber6
Copy link
Contributor

jhuber6 commented Mar 24, 2025

I'm unsure, my gut feeling is that we shouldn't need to carry changes in LLVM just to make an external user's tree easier to use when there's an existing way to work around it. @nikic WDYT?

@nikic
Copy link
Contributor

nikic commented Apr 2, 2025

@jhuber6 The standalone build for LLVM is largely expected to work out of the box, as documented in https://llvm.org/docs/GettingStarted.html#stand-alone-builds. It lists which subprojects llvm can depend on (llvm, cmake, third-party) and only those should be necessary. We could of course add libc to that list, but making that a requirement seems of dubious value at this point. So I do think we should be catering to that use case.

I'm somewhat skeptical about the original change itself though (left a comment at #132096 (comment)). There was some discussion about adding a dependency on libc at some point to provide FP libcall implementations, but I didn't really expect it to be added for this reason and at this point in time (with libc's current maturity level, such as inability to be built for key platforms).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmake Build system in general and CMake in particular
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants