add nvptx_target_feature

[jedbrown]

Tracking issue: #141468 (nvptx), which is part of #44839 (catch-all arches)
The feature gate is #![feature(nvptx_target_feature)]

This exposes the target features sm_20 through sm_120a as defined by LLVM.

Cc: @gonzalobg
@rustbot label +O-NVPTX +A-target-feature

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jedbrown]

Do I need to create a dedicated tracking issue or can I reuse #44839?

I have an associated patch for rust-lang/stdarch that provides a fix for #137086. Can I submit that while this PR is still in review?

[jedbrown]

It looks like the failing build environment is using LLVM-18 (sm_100 onward were added recently llvm/llvm-project#124155). I could remove those entirely (such hardware isn't available yet) or guard them based on LLVM version (how?).

[gonzalobg]

This exposes the target features sm_20 through sm_120a as defined by LLVM.

IIUC LLVM exposes these as target CPUs (Proc) above, not target features, but I think it is fine to expose these as target features in Rust.

[gonzalobg]

I think it'd be good to have more testing (could be punted into an issue and done later):

1. A basic fail test that tries to compile for sm_xx but uses an op that is only available in sm_yy.
   • A pass version of this test that guards the op correctly using cfg!
2. A test that compiles for sm_yy, uses an op that is supported for sm_xx but not in sm_yy even though yy > xx, and therefore fails to compile. That is guarding the op on sm_yy does not suffice, it needs to be precisely guarded on sm_xx.
3. A test that compiles for sm_xx, uses an op that is supported for sm_xx, but the PTX ISA version used does not support this op.
   • I think the proposed solution is not sufficient to guard these ops. The proposed scheme may need to be extended, e.g., to be able to also guard on PTX ISA versions and treating "ptx82" as a target feature), or maybe we need a different solution (exposing target-features describing functionality and do the SM+PTX math in rustc; or expose ptx ISA version and then build in stdarch, etc.).

I think it'd also be good to have more docs:

• The nvptx target docs should describe these:

  rust/src/doc/rustc/src/platform-support/nvptx64-nvidia-cuda.md

  Lines 25 to 26 in 1370611

  	Are there notable `#[target_feature(...)]` or `-C target-feature=` values that
  	programs may wish to use?

• The stdarch docs mention "CPU" throughout, but then list the nvptx target, I think "CPU" should be removed: https://github.com/rust-lang/stdarch/blob/9426bb56586c6ae4095a2dcbd66c570253e6fb32/crates/core_arch/src/core_arch_docs.md

[taiki-e]

@jedbrown

It looks like the failing build environment is using LLVM-18 (sm_100 onward were added recently llvm/llvm-project#124155). I could remove those entirely (such hardware isn't available yet) or guard them based on LLVM version (how?).

You can address this issue by modifying to_llvm_features function in rustc_codegen_llvm/src/llvm_util.rs like some riscv features do:

rust/compiler/rustc_codegen_llvm/src/llvm_util.rs

Lines 280 to 285 in c4b38a5

	// Filter out features that are not supported by the current LLVM version
	("riscv32" | "riscv64", "zaamo") if get_version().0 < 19 => None,
	("riscv32" | "riscv64", "zabha") if get_version().0 < 19 => None,
	("riscv32" | "riscv64", "zalrsc") if get_version().0 < 19 => None,
	("riscv32" | "riscv64", "zama16b") if get_version().0 < 19 => None,
	("riscv32" | "riscv64", "zacas") if get_version().0 < 20 => None,

---

@gonzalobg

This exposes the target features sm_20 through sm_120a as defined by LLVM.

IIUC LLVM exposes these as target CPUs (Proc) above, not target features, but I think it is fine to expose these as target features in Rust.

LLVM actually supports sm_* on both the features and CPUs. (However, their behavior differs as from the sm_* CPUs both sm_* and ptx* features are enabled, but from the sm_* features only sm_* features are enabled.)

Outputs of both --print target-cpus and --print target-features also show them

$ rustc --target nvptx64-nvidia-cuda --print target-cpus
Available CPUs for this target:
    sm_100
    sm_100a
    sm_101
    sm_101a
    sm_120
    sm_120a
    sm_20
    sm_21
    sm_30   - This is the default target CPU for the current build target (currently nvptx64-nvidia-cuda).
    sm_32
    sm_35
    sm_37
    sm_50
    sm_52
    sm_53
    sm_60
    sm_61
    sm_62
    sm_70
    sm_72
    sm_75
    sm_80
    sm_86
    sm_87
    sm_89
    sm_90
    sm_90a

$ rustc --target nvptx64-nvidia-cuda --print target-features
Features supported by rustc for this target:
    crt-static - Enables C Run-time Libraries to be statically linked.

Code-generation features supported by LLVM for this target:
    ptx32      - Use PTX version 32.
    ptx40      - Use PTX version 40.
    ptx41      - Use PTX version 41.
    ptx42      - Use PTX version 42.
    ptx43      - Use PTX version 43.
    ptx50      - Use PTX version 50.
    ptx60      - Use PTX version 60.
    ptx61      - Use PTX version 61.
    ptx62      - Use PTX version 62.
    ptx63      - Use PTX version 63.
    ptx64      - Use PTX version 64.
    ptx65      - Use PTX version 65.
    ptx70      - Use PTX version 70.
    ptx71      - Use PTX version 71.
    ptx72      - Use PTX version 72.
    ptx73      - Use PTX version 73.
    ptx74      - Use PTX version 74.
    ptx75      - Use PTX version 75.
    ptx76      - Use PTX version 76.
    ptx77      - Use PTX version 77.
    ptx78      - Use PTX version 78.
    ptx80      - Use PTX version 80.
    ptx81      - Use PTX version 81.
    ptx82      - Use PTX version 82.
    ptx83      - Use PTX version 83.
    ptx84      - Use PTX version 84.
    ptx85      - Use PTX version 85.
    ptx86      - Use PTX version 86.
    ptx87      - Use PTX version 87.
    sm_100     - Target SM 100.
    sm_100a    - Target SM 100a.
    sm_101     - Target SM 101.
    sm_101a    - Target SM 101a.
    sm_120     - Target SM 120.
    sm_120a    - Target SM 120a.
    sm_20      - Target SM 20.
    sm_21      - Target SM 21.
    sm_30      - Target SM 30.
    sm_32      - Target SM 32.
    sm_35      - Target SM 35.
    sm_37      - Target SM 37.
    sm_50      - Target SM 50.
    sm_52      - Target SM 52.
    sm_53      - Target SM 53.
    sm_60      - Target SM 60.
    sm_61      - Target SM 61.
    sm_62      - Target SM 62.
    sm_70      - Target SM 70.
    sm_72      - Target SM 72.
    sm_75      - Target SM 75.
    sm_80      - Target SM 80.
    sm_86      - Target SM 86.
    sm_87      - Target SM 87.
    sm_89      - Target SM 89.
    sm_90      - Target SM 90.
    sm_90a     - Target SM 90a.

Use +feature to enable a feature, or -feature to disable it.
For example, rustc -C target-cpu=mycpu -C target-feature=+feature1,-feature2

Code-generation features cannot be used in cfg or #[target_feature],
and may be renamed or removed in a future version of LLVM or rustc.

[taiki-e]

Btw, is it intentional that the ptx* target features are not added? My understanding is that we need to check both sm_* and ptx* to use some of the functionality, like LLVM does here.

[jedbrown]

Thanks @taiki-e. I'll update accordingly. I'm seeing PTX 7.8 being written in an otherwise-default configuration with target sm_89. Do you know where such defaults are set?

[jedbrown]

I updated to add the ptx* features and to fix dependencies within the sm_* chain (and deal with the LLVM 20 requirement).

One remaining issue (for the tests @gonzalobg requested) is that #[target_feature(enable = "sm_70")] does not prevent compilation when that target feature isn't present. You can still call the intrinsic unsafely. With respect to PTX requirements, this leads to confusing linker errors. Is there a proper way to enforce this?

[bors]

☔ The latest upstream changes (presumably #139229) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

[jedbrown]

I rebased. The warnings for implied features were fixed by #140920. I updated a stale comment left behind in that refactor, and my handling of features transitively implied by base features moved to rustc_codegen_ssa.

[jedbrown]

@wesleywiser 👋 What are the next steps for this PR?

[ZuseZ4]

It looks like all the feedback was addressed. I went through the PR and so far the changes look sensible to me, and seem to unblock some follow-up work. Since it's properly feature gated and

Tier 2 target-specific code is not closely scrutinized by Rust team(s) when modifications are made.

I don't think we should let this work be blocked for longer.

@bors r+

[bors]

📌 Commit 35a485d has been approved by ZuseZ4

It is now in the queue for this repository.