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(tile_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. Everything lives under cuda-oxide/; cutile-rs is untouched.

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, the newer version a newer one names, and 13.5 when none can read them yet.

Implementation

• oxide-tilebc is a new crate that writes the two descriptions as Tile IR bytecode (preview$func extern and preview$extern_impl, with the fragment types and layouts they carry). It has a typed model, a structural verifier with the Tile compiler's rules, and a textual printer in the upstream form for the --dump output. It writes nothing else of the format; ordinary kernels are not touched.
• 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, writes 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 a7c465e9d:

• ✅ oxide-tilebc 15 tests (hand-built byte tables, verifier rules, version parsing), clippy with warnings as errors, 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 a 13.5-capable tileiras: cargo oxide tilelib builds tilelib_relu.tilelib, and the Tile C++ kernel calls all three exports through it (3 of 3, bit for bit). The decoded descriptions equal the accepted reference bytecode.
• ✅ 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 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.