Give every tensor value one definition while tracking storage separately

For a straight-line region, write x0 for the input, x1 for twice x0, and x2 for x1 plus one. A later reassignment in source code becomes another definition rather than changing what x1 means. This makes a transformation's obligations visible: replacing x2 requires preserving the values reaching its users. For a tensor, shape and element type attach to the value as part of its type or metadata. Matching shapes does not make two definitions interchangeable when they compute different contents.

Definitions also obey scope and dominance rules appropriate to their region. In an ordinary control-flow SSA region, a value used after a branch must be available along the executed incoming path. Moving a definition from one arm into a shared successor can leave the other arm with no valid definition. The LLVM 20.1.0 verifier checks well-formedness conditions, including dominance; it does not prove that an otherwise well-formed rewrite computes the same function. A legal-looking name is only the beginning of a correctness argument.

Suppose a condition chooses either x0+1 or twice x0. The shared successor needs the result produced by the arm that actually ran. LLVM commonly expresses this with a phi instruction; MLIR control-flow regions use block arguments supplied by predecessor terminators. Neither notation means both alternatives were executed, averaged, or concatenated. A transformation that speculatively executes both arms additionally needs permission to perform every operation that previously ran only conditionally, including any potential effects or invalid accesses.

For a matrix-valued merge, incoming tensor types must satisfy the operation's type rules, but equal type does not erase path identity. If both arms yield shape [2,2], the selected contents can still differ in every entry. A compiler must preserve the predecessor-to-value association when rewriting control flow. This is especially important for loop-carried values: each iteration receives a new logical state, even when lowering later implements that state with a small fixed set of buffers.

Consider tensor t0=[[1,2],[3,4]] and t1 obtained by replacing its upper-left entry with nine. A tensor operation can define t1 while t0 remains the original logical value. If a later operation reads t0[0,0], in-place reuse that overwrites its only available storage would incorrectly return nine instead of one. If no old contents are needed and the buffer is writable, reuse may be valid. The analysis must inspect actual uses and aliasing, rather than infer safety from different SSA names.

The network lab supplies a small pure expression whose intermediate definitions can be named on paper. Reset, set both input x=1 and weight w=2, and name the product, biased logit, and sigmoid result before Play or Step. Predict product two, logit 1.5, and output about 0.8176. Reset and set both x=1,w=1 to compare the new definitions. The instrument evaluates one scalar expression; it neither constructs SSA blocks nor allocates aliased tensors, so it cannot certify a proposed buffer-reuse transformation.