Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(cutile): add raw-offset memory ops with generic forwarding support

Open
  • Is something wrong?
#1,426 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
rust
Domain
backend

Research direction

The issue says the work is tracked by the closed NVlabs/cutile-rs PR #229 and points to AGENTS.md for the transplant procedure; start there before investigating the original PR. The referenced tests are cutile/tests/raw_memory.rs and cutile/tests/type_conversion_ops.rs, with compiler support also required. Done means recreating and validating the work against NVIDIA/cuda-rust; the issue reports GPU tests were not rerun after the rebase.

Written by the indexing model from the issue text.

Description

cutile-rs post-migration-pr

Tracks pull request NVlabs/cutile-rs#229 (https://github.com/NVlabs/cutile-rs/pull/229) by @lucifer1004, opened 2026-08-20: feat(cutile): add raw-offset memory ops with generic forwarding support. The branch was rebased onto cutile-rs main on 2026-10-07 and merges cleanly.

@lucifer1004: that repository has moved here and is being archived, so the pull request is closed there, not rejected. If you want to continue the work, please recreate it against NVIDIA/cuda-rust. AGENTS.md in NVIDIA/cuda-rust has a "Transplanting a cutile-rs pull request" section that lets an agent do the replay (it fetches pull/229/head from NVlabs/cutile-rs, keeps your authorship and sign-off, and maps the moved paths).

Original description:

Motivation

Packed layouts (e.g. sparse/quantized weight formats) keep values and metadata at independent byte offsets from a raw base pointer, outside any Tensor view. Today expressing that access pattern in the DSL requires manually composing pointer_to_tile / reshape_ptr / broadcast_ptr / addptr_tile at every call site.

What this adds

Zero-cost raw-offset memory helpers in cutile::core, built entirely on existing pointer-tile primitives:

  • load_offset(base, offsets, ...) — load base + offsets (offsets in elements of B)
  • load_offset_as(base, offsets, ...) — same addressing, then reinterpret each address as E; a *mut u8 base gives byte-addressed access to packed values with independently placed metadata
  • store_offset(base, offsets, value, ...) — store to base + offsets

All three are unsafe fn, like the load_ptr_tko / store_ptr_tko they wrap, with the same safety contract. They are variadic_op wrappers forwarding ordering / scope / mask / padding / token / latency through to load_ptr_tko / store_ptr_tko, so they carry no lowering cost of their own (verified in the test: no make_gather_scatter_view, plain offset + load_ptr_tko/store_ptr_tko in the MLIR).

Compiler support required

Because the wrappers receive marker arguments (ordering, scope, Latency<N>) by value and forward them, the compiler previously could not resolve them — primitives like load_ptr_tko only accepted literal type paths at the call site. This PR teaches the compiler to:

  • resolve forwarded ZST type names through local variables and generic instantiations (extract_forwarded_zst_type_name);
  • resolve Latency<N> cycle counts from a variable's type, including const-generic values;
  • compile inlined Some payloads and explicitly typed None::<T> arguments;
  • treat Option<T> as resolvable/fully-known when its payload is, and infer tuple types element-wise.

It also moves the Latency<const CYCLES: i32> marker into core proper (previously a top-level struct re-exported into core) so the DSL name resolver indexes it for single-segment paths like Latency::<4> — a re-export alone is invisible to the resolver.

Tests

  • cutile/tests/raw_memory.rs (new): compiles kernels using the helpers and asserts the lowered MLIR (offset arithmetic, ordering/scope/latency forwarding, token threading, no gather/scatter view materialization).
  • cutile/tests/type_conversion_ops.rs: F32→E8M0 conversion coverage with positive-infinity rounding (compile-time MLIR check + GPU execution roundtrip).

After the rebase onto current main: cargo test -p cutile-compiler --lib and cargo test -p cutile --test raw_memory pass, and cargo clippy -p cutile-compiler -p cutile --tests -- -D warnings is clean. cargo test -p cutile --tests fails the same tests as main, plus the new GPU test execute_f32_to_e8m0_positive_inf, because tileiras is not available in my current environment; the GPU tests were not re-run after the rebase.

🤖 Generated with Claude Code

Dominant language
Rust
Stars
3.7k
Forks
312
Avg merge
6d 5h
Merged PRs (30d)
68

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NVIDIA/cuda-rust

All issues in NVIDIA/cuda-rust

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.