Tile libraries: call Rust device functions from Tile kernels

[nihalpasham]

What this adds

A Rust device function can now be called from inside a Tile kernel. #[tile_export] marks the function, and cargo oxide tilelib packages the crate as a .tilelib, the static tile library format tileiras links with -l.

before: a Tile kernel and a Rust kernel could only share a stream and buffers
after:  a Tile kernel calls the Rust function in its body, one invocation per tile element

#[tile_export(shape = 128)]
pub fn relu(x: f32) -> f32 {
    if x > 0.0 { x } else { 0.0 }
}

cargo oxide tilelib tilelib_relu --arch sm_120   # -> tilelib_relu.tilelib

cuda-oxide is the SIMT provider: it ships the code (LTOIR from the existing pipeline) and two small descriptions (the interface and the implementation, as Tile IR bytecode). tileiras does the matching, marshalling and linking. The Tile side only emits the call.

The contract

• in scalars are passed by value, &T, &mut T and fixed arrays as pointers, and a scalar return value becomes a trailing out pointer. #[tile_export] generates that wrapper next to the function.
• sync = "warp" means 32 lanes call the function together, so warp shuffles are legal inside it.
• Preview content is read only at the assembler's current bytecode version. The command asks the installed tileiras and writes the descriptions at that version: 13.5 for a CUDA 13.5 assembler, 13.6 for the 13.6 one, and 13.5 when none can read them yet.

Implementation

• cutile-ir writes the Tile IR 13.5 and 13.6 preview content: preview$func extern, preview$extern_impl, preview$call, fragment types and the symbolic layout attributes, behind a typed tilelib API, with a decoder and a structural verifier. The default version for ordinary kernels stays 13.4.
• oxide-tile-export is the shared description vocabulary and its rules (one dimension, one footprint per export, written parameters as one contiguous run, whole warps for warp sync).
• #[tile_export] generates the extern "C" wrapper plus a host-only metadata function whose body is the JSON description; the backend reads it from MIR, roots the wrapper, and writes <crate>.tileexports.json beside the device artifact.
• cargo oxide tilelib runs emit-ltoir, checks that the NVVM IR defines every symbol with the parameters the ABI predicts, builds both bytecode halves, and calls tileiras --preview-create-tile-lib. On an older assembler it stops after the descriptions with exit 2, or exit 0 with --library-optional, which is how the smoketest's new tilelib lane runs it.
• The tilelib_relu example has three consumers: a host program that proves the ABI on CUDA 13.4 (a CUDA C++ caller generated from the descriptions, linked with nvJitLink), a Tile C++ kernel (cpp/tile_caller.cu), and a cuTile Python kernel (python/call_from_cutile.py).

Verification

Checked at d1b988b2:

• ✅ cutile-ir: 14 test suites (hand-built byte tests, decoder round trips, fixture text equal to the upstream Tile IR fixtures, and the preview$call bytes equal to cuTile Python's), clippy, rustdoc.
• ✅ cargo-oxide 255 tests, cuda-macros 132 tests plus the trybuild pass and nine compile-fail cases, oxide-tile-export 16 tests; all 18 repository guards, lockfile sync, cargo deny, book with warnings as errors.
• ✅ RTX 5090: cargo oxide run tilelib_relu verifies all three exports through the native ABI on CUDA 13.4.
• ✅ RTX 5090 with the CUDA 13.6 development toolkit: cargo oxide tilelib builds tilelib_relu.tilelib, and the Tile C++ kernel calls all three exports through it (3 of 3, bit for bit).
• ✅ cuTile Python 1.7 dry run: the kernel compiles to 13.5 bytecode carrying the preview$call to relu.

Caveats

• The .tilelib itself needs a CUDA 13.5 or newer tileiras; on 13.4 the command writes the descriptions and the LTOIR and says so.
• The cuTile Python run needs a cuTile Python that lists the assembler's bytecode version. The 1.7 release stops at 13.5, so it cannot drive the 13.6 development assembler yet; the Tile C++ path has no such gap.
• One-dimensional tiles, f16 but not bf16, concrete shapes only. Linkage providers (implementations compiled on demand) are not part of this change.
• cargo-oxide now depends on cutile-rs/cutile-ir by path, so the SIMT CI lanes also watch that directory.