feat(llvm): add llvm19 support for compute_100+#375
Merged
LegNeato merged 3 commits intoRust-GPU:mainfrom Apr 29, 2026
Merged
Conversation
brandonros
changed the title
Contributor
Author
|
@LegNeato this is a much cleaner approach, what do you think? can we see if CI passes? |
brandonros
force-pushed
the
llvm19-cfg
branch
10 times, most recently
from
2b397fc to
f53e57d
Compare
Contributor
Author
|
proof it works in a limited capacity? |
brandonros
force-pushed
the
llvm19-cfg
branch
3 times, most recently
from
2feadba to
f37288a
Compare
Contributor
Author
|
@CharryWu thoughts? |
brandonros
commented
Apr 20, 2026
| #[cfg(cuMemPrefetchAsync_v2)] | ||
| driver_sys::CUmemLocation { | ||
| type_: driver_sys::CUmemLocationType::CU_MEM_LOCATION_TYPE_DEVICE, | ||
| #[cfg(cuMemLocation_anon_id)] |
Contributor
Author
Add the initial llvm19 cargo/build.rs plumbing while preserving the llvm7\ncheck path. Assemble a v19 libintrinsics bitcode at build time and route\nnvvm.rs through the build-script-provided path.\n\nDocument the validated baseline on the current host and the first Layer 1\nblocker: the existing C++ shim no longer builds unchanged against LLVM 19\nbecause rustllvm.h still expects headers like llvm/ADT/Triple.h. RUST_CUDA_ALLOW_LEGACY_ARCH_WITH_LLVM19 compute_100 target working through compilation errors working throw sigsegv on vecadd nix flake libintrinsics libintrinsics chore(llvm19): close out Layer 3 pre-smoke work Finalize the Layer 3 plan, add env-driven final-module and LLVM IR capture hooks to vecadd, and validate the harness locally so the next phase can move straight to CUDA 12.9+ smoke testing. refactor(llvm19): close out Layer 2 containment Add named Rust-side containment helpers for debug info and target machine creation, make the current ThinLTO behavior explicit, and update LLVM19_PLAN.md to mark Layers 2c and 2d complete. refactor(llvm19): start Layer 2 helper containment Add a small Rust-side helper surface in src/llvm.rs for call-building, symbol insertion, and debug-location setting, then migrate the obvious callers without introducing LLVM-version cfg branching. Update LLVM19_PLAN.md to reflect the real Layer 2 state: 2a is complete, 2b is complete, 2c is partially landed, and 2d is still pending. Include the current .gitignore change in this checkpoint as requested. feat(llvm19): complete Layer 1 C++ shim bridge Bridge the wrapper headers and C++ shims so rustc_codegen_nvvm now builds against both LLVM 7 and LLVM 19. This adds the LLVM 19 wrapper headers, ports RustWrapper.cpp and PassWrapper.cpp through the current checkpoint, and records the completed Layer 1 progress and remaining Layer 2 caveats in the plan. ptxjitcompiler.so load_ptx_with_log unified? Co-Authored-By: OpenAI Codex <codex@openai.com>
Contributor
Author
|
CI passed all the way to docs, if we could allow it once more. thank you!!! |
LegNeato
requested changes
Apr 25, 2026
Contributor
LegNeato
left a comment
LegNeato
left a comment
There was a problem hiding this comment.
Thanks for jamming on this! Some small comments.
…eature Replace the LLVM_CONFIG_19 env-var sniffing in `cuda_builder` with a proper `llvm19` cargo feature, addressing review feedback on Rust-GPU#375. - `nvvm` gains an `llvm19` feature; `NvvmArch`'s `#[default]` is moved off `Compute75` and onto `Compute100` via `cfg_attr` when it's enabled, so `NvvmArch::default()` returns the right answer for the active dialect. - `cuda_builder` gains a matching `llvm19` feature that propagates to `nvvm/llvm19` and (when the optional dep is on) `rustc_codegen_nvvm/llvm19`. `CudaBuilder::new` goes back to plain `NvvmArch::default()`. - The build script's nested `cargo build -p rustc_codegen_nvvm` now keys the `--features llvm19` flag off `cfg!(feature = "llvm19")` instead of the env var, so the toggle lives in one place. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`--all-features` on the docs job activates `cuda_builder/llvm19`, which now propagates `rustc_codegen_nvvm/llvm19` (added in ebfe81b for feature-graph consistency). That forces the dep build of `rustc_codegen_nvvm` onto the LLVM 19 path, which fails in CI because no LLVM 19 toolchain is installed. Run docs in two passes: `--all-features` over the workspace minus the three crates that gate behind `llvm19`, then default-features over those three. This restores green CI on the LLVM 7 path the existing images support. Known gap: `cfg(feature = "llvm19")` code paths inside those three crates aren't rustdoc-checked. Closing that gap properly needs LLVM 19 in the CI images and is left as a follow-up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
Awesome, let's land this and iterate! |
Contributor
Author
|
dang, you do not mess around!!! thank you for your support! will continue banging on it/improving it. will keep an eye on issues queue if anything pops up. it's a sleeping default for now i hope with no impact. i'll improve the CI story so we can lower friction to those who want to test it out. a mini call to arms of "help us test blackwell++" might be interesting. stress test it. i'll try to hit it with some of the complex ed25519 math i was doing before and see if i can get it to break. thanks again! |
pull Bot
pushed a commit
to Haofei/Rust-CUDA
that referenced
this pull request
Apr 29, 2026
…eature Replace the LLVM_CONFIG_19 env-var sniffing in `cuda_builder` with a proper `llvm19` cargo feature, addressing review feedback on Rust-GPU#375. - `nvvm` gains an `llvm19` feature; `NvvmArch`'s `#[default]` is moved off `Compute75` and onto `Compute100` via `cfg_attr` when it's enabled, so `NvvmArch::default()` returns the right answer for the active dialect. - `cuda_builder` gains a matching `llvm19` feature that propagates to `nvvm/llvm19` and (when the optional dep is on) `rustc_codegen_nvvm/llvm19`. `CudaBuilder::new` goes back to plain `NvvmArch::default()`. - The build script's nested `cargo build -p rustc_codegen_nvvm` now keys the `--features llvm19` flag off `cfg!(feature = "llvm19")` instead of the env var, so the toggle lives in one place. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
2 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.
attempt 2 of #227