You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@LegNeato I did not feel there was a lot of good warm than reception on that approach.
This repo is really cool because you are taking over somebody's extremely hard to do rustc_codegen approach from LLVMv7
Is there any appetite to consider alternatives?
I get that Blackwell is very early and a very small piece of the market, but if we are forward looking, I would guess that within the next two years, the majority of the market will be using this new LLVM v19 version of NVVM/etc
I would like to sync with you on this, I am sure you were busy, but I basically came up with two different approaches
One of them is the one that I PR'd where I fumbled through making a new rustc_codegen
Another is where I give up a ton of flexibility related to address space but I was able to do LLVM IR -> NVVM which I would really like to show you and get some feedback on whenever you have time
@brandonros I took a look at your approach, my main concern is I don't understand the tradeoffs. I also expect that would be harder to get into the compiler proper. But again, I don't really know. I would imagine if we are in rustc we can distribute nvvm or compiled llvm7 in its own component and we'd have to probably do the same for LLVM v19 as I don't think nvidia is going to track LLVM versions with NVVM like rustc does (but who knows!). So this llvm stuff is only a problem because we don't have all the rustup / rustc infra as an external codegen backend.
What I dont want to do is reimplement most things that NVIDIA handles. That's a fools errand...we want to swim with them rather than try to reimplement everything (minus some bits that maybe are a pain or need to be rust-native).
I'm trying to use the precompiled libraries available here https://github.com/awakecoding/llvm-prebuilt/releases to rematch parts of the Rust wrapper and the relevant code generation. I understand your concerns, but this task also requires a good understanding of some APIs in LLVM and NVVM. Perhaps I should write a document to summarize the current work and then simultaneously address the issues of API matching and code adaptation. What do you think? @LegNeato
we should only need 7.1 (for older nvvm) and 18 (for newer nvvm) from the CUDA side (and rustc will have a third for CPU side, and that is a moving target). I'm not sure how often nvidia will update nvvm going forward.
Yes, we want end users to not worry about nvvvm/llvm, similar to how in normal rust you just get llvm with rustc.
@LegNeato Okay, I get it. I'll take it step by step, making sure that we know what we're doing at each stage—something that's testable, explainable, and backed by solid reasoning.
Activity
LegNeato commentedon Jul 1, 2025
@brandonros did some experiments with emitting llvm ir and then using llvm-bitcode-linker I believe. Care to comment on if this path is viable?
brandonros commentedon Jul 1, 2025
@LegNeato I did not feel there was a lot of good warm than reception on that approach.
This repo is really cool because you are taking over somebody's extremely hard to do rustc_codegen approach from LLVMv7
Is there any appetite to consider alternatives?
I get that Blackwell is very early and a very small piece of the market, but if we are forward looking, I would guess that within the next two years, the majority of the market will be using this new LLVM v19 version of NVVM/etc
I would like to sync with you on this, I am sure you were busy, but I basically came up with two different approaches
One of them is the one that I PR'd where I fumbled through making a new rustc_codegen
Another is where I give up a ton of flexibility related to address space but I was able to do LLVM IR -> NVVM which I would really like to show you and get some feedback on whenever you have time
LegNeato commentedon Jul 12, 2025
I wonder if we can statically link it in, so at least users don't need it installed.
LegNeato commentedon Jul 16, 2025
@brandonros I took a look at your approach, my main concern is I don't understand the tradeoffs. I also expect that would be harder to get into the compiler proper. But again, I don't really know. I would imagine if we are in rustc we can distribute nvvm or compiled llvm7 in its own component and we'd have to probably do the same for LLVM v19 as I don't think nvidia is going to track LLVM versions with NVVM like rustc does (but who knows!). So this llvm stuff is only a problem because we don't have all the rustup / rustc infra as an external codegen backend.
LegNeato commentedon Jul 16, 2025
What I dont want to do is reimplement most things that NVIDIA handles. That's a fools errand...we want to swim with them rather than try to reimplement everything (minus some bits that maybe are a pain or need to be rust-native).
devillove084 commentedon Jul 22, 2025
I'm trying to use the precompiled libraries available here https://github.com/awakecoding/llvm-prebuilt/releases to rematch parts of the Rust wrapper and the relevant code generation. I understand your concerns, but this task also requires a good understanding of some APIs in LLVM and NVVM. Perhaps I should write a document to summarize the current work and then simultaneously address the issues of API matching and code adaptation. What do you think? @LegNeato
LegNeato commentedon Jul 23, 2025
Sure, whatever works for you. I am not familiar with this part of the project so don't have any strong opinions.
I think ideally we:
devillove084 commentedon Jul 23, 2025
@LegNeato
LegNeato commentedon Jul 23, 2025
@devillove084
we should only need 7.1 (for older nvvm) and 18 (for newer nvvm) from the CUDA side (and rustc will have a third for CPU side, and that is a moving target). I'm not sure how often nvidia will update nvvm going forward.
Yes, we want end users to not worry about nvvvm/llvm, similar to how in normal rust you just get llvm with rustc.
The current docker stuff is pushed here: https://github.com/orgs/Rust-GPU/packages?repo_name=Rust-CUDA. The Dockerfiles are in the repo.
devillove084 commentedon Jul 23, 2025
@LegNeato Okay, I get it. I'll take it step by step, making sure that we know what we're doing at each stage—something that's testable, explainable, and backed by solid reasoning.