Module Ir.C_syntax

Whether a compiled routine's tensorization request was honoured (gh-ocannl-626). Three states, not a boolean, because "this routine has no tensor-core work in it" and "this routine asked for tensor-core work and got the scalar fallback" are opposite readings of a timing and the boolean that collapses them is the defect: an Tile_mma-free routine is not a failure, a wholly declined one is. Mixed renderings — some statements honoured, some declined — read as Tensorized, and the counts on mma_summary say by how much; the label answers "did any tensor-core / SIMD-tile emission happen", the counts answer "how much of what was asked for".

What a compile's mma_census says about the routine it produced (gh-ocannl-626). Derived once, where the routine is compiled, so that "did this tensorize" is a property of the compiled routine rather than of whichever call site remembered to bracket the global.

The one-line census a timing report prints beside a measurement (gh-ocannl-626): the tensorization label first — a reader scanning a table for a mismatch reads that word, not a histogram — then the per-rendering counts. Shared so that every harness that names a variant after a rendering says "did this tensorize" the same way; the two bench copies had disagreed about the predicate (one counted the fallback, the other tested equality with Mma_register_tiled, which false-warns on any GPU backend).

Run f with the mma_census collecting, and return its result alongside the summary of what rendered during it (gh-ocannl-626). Both census refs are saved and restored, so calls nest and an inner compile does not disturb an outer collection; the summary covers only f's own entries. This replaces the hand-rolled Exn.protect bracket that had been copied to six call sites — and, applied inside Context.compile, makes collecting the census the default rather than something a timing harness must remember to do.

The census is a process global, as it always was: compiles are sequential on the main domain, and nothing here makes concurrent compiles from several domains attribute their renderings correctly.

What a localizing site DECIDED (gh-ocannl-733). A named record rather than an inline one so a consumer can hold one: comparing the verdicts of two compiles is the whole use.

What a compile's peel_census says about the routine it produced (gh-ocannl-733).

The one-line peel census a report prints beside a routine (gh-ocannl-733): how many reduction sites localized, and the distinct verdicts they earned.

Run f with the peel_census collecting, and return its result alongside the summary of what the reduction peel decided during it (gh-ocannl-733). Nests additively and restores both refs, exactly as with_census does for the Tile_mma census — and for the same reason: an enclosing collection must still see an inner compile's sites.

What a compile's volatility census says about the routine it produced (gh-ocannl-782).

The one-line volatility census a report prints beside a routine (gh-ocannl-782/820): how many serial accumulations this routine carries and how many selected the volatile-read workaround.

Run f with the volatility census collecting, and return its result alongside the summary of what the accumulation workaround decided during it (gh-ocannl-782). Nests additively and restores the refs, exactly as with_census and with_peel_census do.

The address space of a tile-MMA operand as the emission hooks see it.

The physical layout of a tile-MMA operand's storage (gh-ocannl-481 item 3, D2). This is the whole Stage -> emission contract: the emission never re-derives the layout, it trusts the component it is handed.

`Swizzled_elem operands never reach a hook — the Tile_mma rendering declines them centrally, since no intrinsic load form matches an element-granularity permutation. `Swizzled_b128 is only passed when the access is reconstructible from (ptr, ld) alone: the pointer is the tile origin of a rank-2 node whose minor dim is ld, so the element at (row, col) sits at row*ld + (((col/u) lxor (row land (ld/u - 1))) * u) with u = 16 / prec_in_bytes — everything else declines.

A tile-MMA input operand described but not addressed: leading-dimension stride in elements, address space, physical layout — no pointer. This is how the a and b operands reach both emission hooks, because a caller does not always have an address to give: a software-pipelined tile's live copy rotates per k-block (gh-ocannl-487), so its pointer only exists inside the rotor loop, and C_syntax_config.mma_fragment_syntax runs outside it.

Everything an arm decides acceptance by is here — the pointer never was a criterion.

The emitting half of an accepted C_syntax_config.mma_syntax call: the arm has committed, and only the a/b tile addresses are still outstanding. Splitting the hook this way makes Option.is_some (mma_syntax ...) a support predicate usable wherever a call is known but not yet addressed — with no separate acceptance implementation that could drift from the emitting one.

gh-ocannl-487 phase 2: asynchronous staging copies for software-pipelined tiles (see C_syntax_config.async_copy).

Whether c lies exactly halfway between two adjacent f32 values, so that narrowing it to f32 is a tie that IEEE-754 breaks to even -- and any decimal near but not equal to c would instead break by whichever side it fell on.

Computed against the two neighbours rather than by masking mantissa bits, so that the f32 subnormal range (where the retained-bit count shrinks, and a bit mask would need a second case) is covered by the same three lines. Values that overflow f32 have no neighbours to sit between and are not ties.

A C source literal for the floating-point constant c, as a double-typed floating literal that parses back to exactly c on every C-family backend.

Three properties, each of which %.16g alone gets wrong (gh-ocannl-623). Two of them are not C's alone — a debug dump wants a floating literal that round-trips for the same reasons a kernel does — so they live in Utils.decimal_float_literal, which the IR printers share (gh-ocannl-713):

• It is a floating literal, not an integer one. In C the consequence is direct: 2. came out as the integer literal 2, value-preserving in the cast contexts the constants happen to sit in today — but -0. came out as "-0", the integer zero, hence +0.0 once cast, so a -0.0 in host data silently reached kernels as +0.0 wherever the constant fill inlines as scalar stores (gh-ocannl-615 fixed that one value). The rest of the class is latent rather than inert: an integer literal divides as an integer against another one, promotes as an integer, and would overflow its type once the digits outgrow long long.
• It round-trips. That reaches emitted code for real: hosted constant inits (gh-ocannl-633) inline arbitrary host values as scalar stores, and 0.1 +. 0.2 at 16 digits is a different double. Values that already round-trip at 16 digits keep their exact previous spelling, which is why no codegen golden moves except by the appended .0.
• The specials are spelled, not printed. This one is C's own, and is why the shared rendering is called only after they are ruled out: it leaves them as %.16g's words (inf, nan), which no C dialect parses. INFINITY and NAN are C99 math.h macros that MSL also provides; the CUDA and HIP preludes define them under #ifndef since nvrtc/hiprtc supply no standard headers. (-INFINITY) is parenthesized so it cannot glue into --INFINITY beside a subtraction. A NaN's payload and sign do not survive this (no dialect spells a payload portably); nothing in OCANNL depends on them, and a bit-exact constant has Low_level.scalar_t.Constant_bits available.

Deliberately not carried here: a precision suffix. The literal is always double-typed and the narrowing is B.convert_precision's cast, which is a single rounding of the exact host double — the same conversion the host performs when it stores the value. An f-suffixed decimal would instead round the decimal straight to float. The cast is present for every non-double target: Ops.c_convert_precision and each backend's override return ("", "") only when from and to_ are the same precision.

That last argument has a hole, and is_f32_tie is what fills it: the cast only is a narrowing where the dialect has a double. MSL does not, so Metal rounds the decimal itself, at parse time, to f32. A decimal that round-trips as a double is not thereby exact, so the two readings — round c to f32, versus round a decimal near c to f32 — can differ, and they differ exactly when c sits on an f32 tie: the host takes ties-to-even while the dialect follows whichever side the decimal happens to land on. Which digit count is emitted then decides the value, so this is not a hazard the retry above introduced but one it moves. A hexadecimal literal takes it away instead of moving it: it is exact by construction, so there is no parse-time rounding for either reading to disagree about, and both round c itself. It is spelled only for ties — a handful of values that were otherwise a coin toss — so the ordinary constant keeps its readable decimal, and C99, CUDA, HIP and MSL all accept the form.

The C-family rendering of a binary operation, from Ops.binop_c_syntax: prefix, first operand, infix, second operand (breaking after the operator), suffix.

Outside Pure_C_config because the GPU backends, which shadow binop_syntax wholesale (most ops need target-specific intrinsics or precision bridging), delegate here for the ops that are spelled the same in C, CUDA, HIP and MSL -- the comparisons and the logical connectives. Those then have one spelling (Ops.binop_c_syntax) and one layout (here) across all backends, instead of a copy per backend.

The RNG binops -- the two Threefry variants and the per-lane uniform conversion -- rendered as a call to the builtin of that name. Every C-family backend provides the same three builtins (builtins.c, Builtins_cuda, Builtins_metal) under the same precision contract: the Threefry ops produce a uint4x32 block, and the lane conversion consumes one to produce the target precision, so it is the one binop that rejects uint4x32 (its builtin already yields the target precision, bypassing the generic bfloat16/fp8 compute-in-single wrapping).

Backends pass their own two-argument call renderer -- the layouts differ in where a line break may fall -- and the backend name for the diagnostics. op must be one of the three ops above.

All maximal identifier-like substrings of s -- a run of alphanumerics and underscores starting at a letter or underscore. This decomposes a composite rendering like "(fabsf(floorf(" into ["fabsf"; "floorf"] rather than the concatenation "fabsffloorf".

A run whose first character is preceded by a digit or a . is the tail of a numeric literal (f in "0.0f", h in "1.0h"), not a name, and is skipped -- otherwise every single-letter literal suffix a backend emits would be reserved.

The precisions a backend's renderers are exercised over -- by op_syntax_idents and by operand_conditionality_violations. The operator sweeps use Ops' derived enumerations (Ops.all_of_binop and friends), so a newly added operator joins both checks automatically; Ops.prec cannot be derived the same way -- its constructors carry the phantom-typed precision witness -- so the exhaustive match below stands in for it: adding a precision is a build error here, and the fix is to extend this list (or to leave the precision out deliberately, as Void_prec is, since every renderer rejects it).

Every function and type name a backend's operator rendering can emit, obtained by rendering each (precision, operator) pair over a placeholder operand and harvesting the identifiers.

Rendering the syntax functions is what makes this correct per backend: reading the names off Ops.unop_c_syntax instead would describe *C*, and the GPU backends shadow those functions wholesale. MSL spells Tanh_approx as tanh where C spells it tanhf, so the C-derived list left "tanh" free for a tensor node -- and Tensor.unop's ~op_label makes that an ordinary name, minted by every Operation.tanh. The Metal kernel then declared device float *__restrict tanh and the call on the next line resolved to that pointer (gh-ocannl-553). The same holds for exp, log, sqrt, sin, cos, trunc: unsuffixed in MSL, suffixed in C.

Backends reject some (precision, operator) pairs by raising, either while selecting the renderer or while applying it; those pairs contribute no names. Any escaping exception is swallowed rather than failing the compilation this list only guards.

What a backend's operator renderings actually emit, checked against the operand-evaluation contract they are supposed to implement (Ops.binop_conditionality / Ops.ternop_conditionality) -- returns one message per disagreement, [] when they agree (gh-ocannl-582).

The classifier is what Low_level.affine_accesses and both Cost_model walks consume, and the renderers are the ground truth it describes; checking rather than consulting is deliberate, since a renderer cannot ask "am I allowed to short-circuit here" -- it either emits a conditional or it does not. Each operator is rendered over distinguishable placeholder operands at every precision, and the emitted text is read for the only C-family constructs that can skip an operand: ?:, && and ||. So:

• a projection (Only_first / Only_second) must not mention its discarded operand -- every backend rejects one outright, which satisfies this trivially, and C_syntax.pp_scalar emits the selected operand alone before binop_syntax is ever reached;
• Gated_second must place one of those constructs before its second operand;
• Both_operands / All_three must emit none of them anywhere -- an Ops.Max spelled (a > b ? a : b) would evaluate a twice and b conditionally, and the cost model's floor would keep charging both;
• Cond_and_one_arm must put its arms on the two sides of a ?: alternative, which is what rules out MSL's select (a call: it evaluates both arms, so a range guard lowered to Where would still perform its out-of-range read).

The operator sweep is Ops' derived enumeration, so an operator added to Ops.binop or Ops.ternop is checked here without anyone remembering to list it. A (precision, operator) pair the backend rejects by raising contributes nothing, as in op_syntax_idents.

The names defined by a backend's builtins table (the keys of its (name, definition, dependencies) entries), for its ident_blacklist. A node taking one of these names both shadows the definition and, since filter_and_prepend_builtins selects entries by searching the rendered kernel for their key, drags the definition into a kernel that never calls it.

The words the C language itself reserves, plus the scaffolding names this module's rendering emits unconditionally. Shared by every C-family backend through Pure_C_config, and by C_syntax.kernel_ident: a routine and a tensor node are both plain identifiers in the emitted source, so they are unsafe on exactly the same words.

asm is in the list even though C89/C99 reserve it only as a common extension: every compiler OCANNL emits for (gcc, clang, nvrtc, hiprtc, the Metal front end) treats it as a keyword, which is what made Block_comment "asm" emit void asm( and fail as an "internal" codegen bug (gh-ocannl-686).

Macro names the C-family preludes' unconditional includes define (<stdio.h>, <math.h>, <string.h>, <stdlib.h>, <stdint.h>). Macros are the half of the standard library that NOTHING can shadow -- a parameter or a local named NAN expands mid-declaration and the kernel fails to parse -- so these constrain every identifier, tensor-node names included, and belong in the shared ident_blacklist (gh-ocannl-686).

Function and type names the same unconditional includes declare. Unlike the macros above these are ordinary file-scope declarations, and C scoping makes the two cases genuinely different:

• a routine DEFINITION takes file scope, so void printf(...) after <stdio.h> is a conflicting declaration and void exp(...) after <math.h> likewise -- an error regardless of whether the kernel ever calls either;
• a parameter or a local legally SHADOWS them, so a tensor node named exp is well-formed C and always has been.

So this table constrains routine names only (C_syntax.kernel_ident) and is deliberately kept out of ident_blacklist: adding it there would rename tensor nodes -- Tensor.unop's ~op_labels are exactly these words (exp, log, sqrt, tanh) -- churning goldens to prevent a collision that cannot happen. The names a rendering actually CALLS are a separate concern already covered by op_syntax_idents, which is what stops a node from shadowing a callee the same kernel invokes.

The words C++ reserves on top of c_keywords. CUDA, HIP and MSL are all C++ dialects -- their kernels are parsed by a C++ front end even where the emitted body is plain C -- so their backends extend the blacklist with this table. Several entries are entirely plausible tensor labels or routine names (class, new, operator, bool, this, template), and a collision there is the same misattributed "bug in OCANNL" failure as gh-ocannl-686's asm.

C_syntax_config.full_printf_support for a dialect whose printf does support %g — every backend except Metal, whose MSL printf does not. Such a backend still gives the scaled-integer rendering up when asked for backend uniformity, so that its routine logs read the same as Metal's: the setting is what decides, and it is read here once rather than restated per backend.