Target feature scan splits LLVM IR on ';', so conjunctive predicates match across the whole module (integer redux + any f32 reads as ReduxF32)
Maintainers usually reply within 2 days
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 75/100
Research direction
Start with the target-feature scan at detect.rs:99 and the committed fixture crates/rustc-codegen-cuda/examples/redux_minmax/redux_minmax.ll. Check the other conjunctive contents.split(';') call sites, then use the described regression cases: separate integer redux and f32 operations must not report ReduxF32, while a real f32 redux intrinsic must.
Written by the indexing model from the issue text.
Description
Summary
The target feature scan splits LLVM IR on ; and calls each piece a "statement". In LLVM IR ; starts a comment, so a whole module is typically one or two pieces — and every predicate that asks for two things in the same "statement" is really asking whether both appear anywhere in the module.
Evidence
A committed IR file, crates/rustc-codegen-cuda/examples/redux_minmax/redux_minmax.ll:
bytes: 3093 lines: 98 semicolon-chunks: 2
98 lines, one semicolon. Redux reaches the IR as NVVM intrinsic declarations, not as inline PTX:
declare i32 @llvm.nvvm.redux.sync.min(i32, i32) #0
declare i32 @llvm.nvvm.redux.sync.umin(i32, i32) #0
What it costs
contains_redux_f32_features (detect.rs:99) is the one I tripped:
contents.split(';')
.any(|statement| statement.contains("redux.sync") && statement.contains(".f32"))
A module of mine uses integer warp_reduce (so integer redux.sync declarations) and, in a different kernel, ordinary f32 shuffles. No f32 redux anywhere:
redux mentions in the IR: redux.sync.add, .and, .max, .min, .or, .umax, .umin, .xor
f32 redux: none
It is still rejected:
CUDA target sm_80 cannot lower detected feature ReduxF32 + Sm80;
cuda-oxide requires a target compatible with sm_100a for this module
Because the 42 KB module splits into 2 chunks, and in the chunk that matches, redux.sync is at line 768 and .f32 at line 1315 — 547 lines apart, in unrelated code.
So a module that mixes integer warp reductions with any float work is pushed from sm_80 to sm_100a and refuses to build.
Scope
21 call sites use contents.split(';'). Single-substring predicates are unaffected — a substring is present or not regardless of how the text is cut. The conjunctive ones are the exposed set, e.g.:
contains_redux_f32_features—redux.sync&&.f32contains_multimem_blackwell_features— multimem && (.e4m3|.e5m2|.acc::f16)contains_cluster_scoped_memory_features—!multimem.&&.cluster.&& (ld.|st.|atom.|red.)
The negation in the last one is worth calling out: at module granularity, one multimem. anywhere suppresses cluster-memory detection for the whole module — a false negative, which fails the other way.
Suggested fix
Split on newlines as well as ;. LLVM IR is line-oriented, and where PTX text does appear inline it sits within one line (multi-instruction asm templates escape their newlines as \0A, which is not a newline in the file text). So this is strictly finer than the current split: it can remove false positives and cannot introduce false negatives.
I have the fix and a regression test built from the module above (integer redux declarations plus f32 ops on separate lines must not report ReduxF32; a real declare float @llvm.nvvm.redux.sync.fmin.f32 must). Happy to put it up — it blocks #811, whose warp_reduce fast path is integer-only and lands in modules that also do float work.
Environment
cuda-oxide at b9847e95; detected on an A10G (sm_86) build, reproducible from the IR text alone.
- Dominant language
- Rust
- Stars
- 3.8k
- Forks
- 325
- Avg merge
- 6d 8h
- Merged PRs (30d)
- 66
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from NVIDIA/cuda-rust
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
NVIDIA/cuda-rust#1568 · 1 comment ·
Maintainers usually reply within 2 days
-
[BUG]: The doc of trait `LoadTileLike` is incorrectPossibly taken @akhil9tiet claimed this 6 days ago. Openbug
Difficulty 1/5 Under an hour Newbie friendliness 72/100
NVIDIA/cuda-rust#1523 · 2 comments ·
Maintainers usually reply within 2 days
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 2 days
-
cargo oxide doctor's clang check fails after following its own 'apt install clang-21' remedyMay be free again @letv1nnn claimed this 33 days ago, and no pull request is open. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
NVIDIA/cuda-rust#1302 · 1 comment ·
Maintainers usually reply within 2 days
All issues in NVIDIA/cuda-rust
Similar issues
-
state:triage-needed
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
bug P2
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
pedrovgs/UseCaseCoverage#23 ·
-
area: library data-loss tier: p0 type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day