[FEA]: Add SM arch detection to CUDA-Pathfinder for LLVM bitcode files

[benhg]

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

[rwgk]

Looks good to me, but a small API nit: I’d prefer sm_arch: str | None = None over sm_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_arch be validated/normalized, e.g. accept only sm_90/sm90/90 in a documented form? Deciding that now is easier than hardening the API later.

[benhg]

That's fine to me.

One thing worth thinking about before this becomes a public API: should sm_arch be validated/normalized, e.g. accept only sm_90/sm90/90 in a documented form? Deciding that now is easier than hardening the API later.

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]

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.

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/sm90a at the API boundary, then map to the package filename convention (sm90, etc.) if needed? Mostly I’d like this to be a re.fullmatch-style check rather than free-form string concatenation.

[benhg]

Sounds good to me.