Repository navigation
[FEA]: Add SM arch detection to CUDA-Pathfinder for LLVM bitcode files #2200
Description
Is this a duplicate?
- I confirmed there appear to be no duplicate issues for this request and that I agree to the Code of Conduct
Area
cuda.pathfinder
Is your feature request related to a problem? Please describe.
Since 3.7.0, NVSHMEM must ship arch-specific bitcode files (libnvshmem_device_smXX.bc) instead of libnvshmem_device.bc. The reason for this is that libnvshmem_device.bc was silently an SM90-only file, and that's not really an acceptable solution.
We attempted to ship a libnvshmem_device.bc which is a symlink to SM90 file just for compatibility, but I was unaware that symlinks are not supported in wheels.
So this is really an NVSHMEM Bug, but I think longer-term, there is a valid use case for arch-specific bitcode files.
Note that this is not as much of an issue for LTOIR files as they can be built into Fatbins for many architectures.
Describe the solution you'd like
Add an optional "sm_arch" kwarg to find_bitcode_lib:
cuda.pathfinder.find_bitcode_lib(name: str, sm_arch: str="") → str
If sm_arch is not set, it will find the corresponding .bc file for the library only. If it is set, it will find {lib name}_{sm_arch}.bc
Describe alternatives you've considered
No response
Additional context
No response
Activity
rwgk commentedon Jun 11, 2026
Looks good to me, but a small API nit: I’d prefer
sm_arch: str | None = Noneoversm_arch: str = "", since absence seems semantically cleaner than an empty architecture string.One thing worth thinking about before this becomes a public API: should
sm_archbe validated/normalized, e.g. accept onlysm_90/sm90/90in a documented form? Deciding that now is easier than hardening the API later.benhg commentedon Jun 11, 2026
That's fine to me.
I agree. I don't have a preference. what NVSHMEM does today is sm90, but of course we can change the API surface to wrap around variants for libraries if we need to.
rwgk commentedon Jun 11, 2026
My first choice would be to validate fairly strictly before building the filename. I don’t feel strongly about the public spelling, but I’d prefer we document one canonical form and normalize from there rather than accepting arbitrary suffixes.
Maybe accept something like
sm90/sm90aat the API boundary, then map to the package filename convention (sm90, etc.) if needed? Mostly I’d like this to be are.fullmatch-style check rather than free-form string concatenation.benhg commentedon Jun 11, 2026
Sounds good to me.
rwgk commentedon Jul 1, 2026
Hi @benhg, @leofang is generalizing the pathfinder nvshmem pinning under #2286, as an emergency fix so that our CI goes green again.
I'm a bit concerned if we leave nvshmem >= 3.7.0 as unsupported by pathfinder for an extended period of time. What could we do to avoid that?
benhg commentedon Jul 1, 2026
Hi @rwgk, the easiest thing to do is make pathfinder return just the sm90 bitcode for nvshmem. That matches pre-3.7 behavior.
rwgk commentedon Jul 1, 2026
Between that, and #2201, I'd strongly favor 2201.
Reason: otherwise people will start to hack around the lack of the 2201 feature, e.g. by engineering the path for other sm versions by taking the dirname of what
find_bitcode_lib("nvshmem_device")returns and then manufacture the version-specific full path. So we'll essentially have many adhoc versions of 2201 floating around in the wild. I think we're doing the community a favor by taking a little bit of ownership here to manage the tiny API extension under 2201.@leofang for visibility
benhg commentedon Jul 6, 2026
After discussion, we've decided to change from adding new arguments to find_bitcode_lib, to adding a new function
find_bitcode_lib_by_nameinstead, which will search in that project's lib directory for a specific name. Libraries can wrap that function to provide search across any attributes.rwgk commentedon Jul 20, 2026
I've been thinking through the tradeoffs between the two alternative approaches in #2201 and #2302. I think they optimize for different API requirements:
sm_arch, ABI, LTO mode, and so on.Both approaches draw technically coherent boundaries:
The distinction that matters most to me is that
sm_archis a property of the requested artifact, whereas a filename is a packaging and storage detail. Keeping that detail centralized lets Pathfinder adapt when package layouts or filenames change without pushing the same naming logic into every consumer. It also keeps user code minimal and stable: callers should need to change code only when their artifact requirements change, not merely because a wheel starts using a different raw filename.My preference is therefore to build on #2201 and strengthen its controlled, semantic contract:
find_bitcode_lib(..., sm_arch=None)as the public API.An exact-name lookup can still be useful as an internal implementation primitive. I would prefer to consider exposing that broader, lower-level API only when we have concrete additional use cases that require it.