A saved tensor needs its historical value, not merely its storage address

A tensor view can share storage with another tensor while having different shape or strides. Writing through either alias can change values seen through the other. A reverse rule that saved the original input for x² needs that original input to compute 2x, not the overwritten value. The hazard depends on what the rule saved and whether the mutation occurs before its last use. Some operations can be handled safely through runtime bookkeeping or a derivative that needs different residuals; there is no mathematical rule that every in-place operation is always invalid.

PyTorch 2.9 documents version counters that change when tensors are marked dirty by tracked in-place operations. Saved values record the relevant version, and retrieving them for backward can detect incompatible modification. Leaf-tensor restrictions and graph-rewriting rules impose additional constraints. These checks protect a defined autograd contract; they are not a general detector for arbitrary external writes or all unsafe storage manipulation. Bypassing tracking or mutating through an unsupported interface can defeat the evidence the runtime relies on. An error should lead to identifying the saved-value dependency, not blindly disabling checks.

Detaching can remove a derivative dependency while still sharing underlying storage. Cloning can create separate storage while remaining a differentiable copy in the graph. A detached clone combines different choices about history and storage, but using one blindly can also cut a gradient the model actually needs. State the intended ownership and derivative boundary before choosing an operation. A no-grad context suppresses recording of operations under its rules; it does not make overwriting a value already needed by another backward pass harmless.

Aliases also complicate apparent memory savings. Avoiding a copy may retain a much larger backing allocation or extend its lifetime through a saved view. A copy can increase immediate bytes while allowing the original allocation to be released earlier. Peak memory depends on scheduling and ownership, not just the number of clone calls. Compare a functional reference with the proposed mutation using valid inputs, repeated backward where supported, and the actual transformed graph. Correct forward output alone cannot verify that every historical residual remained available for the derivative.

Write a timeline of forward save, alias creation, mutation, backward read, and storage release. Include optimizer updates and multiple losses sharing a graph: stepping parameters before all intended gradients have been computed can invalidate remaining dependencies. A retained graph preserves access under its contract but does not freeze mutable storage against later writes. Tests should inspect both gradients and expected errors for unsupported schedules. Preserve legitimate dependencies by using a functional formulation or a supported copy/recomputation strategy rather than disguising the mutation as a new graph boundary.

The function lab compares separate evaluations without any tensor aliasing. Reset, explicitly set BOTH a=1 and x=1, predict slope two, then Play or Step. Reset and re-set BOTH a=1 and x=2; predict slope four. These are different selected primal values, not one saved value being safely mutated. Edits retain elapsed t and recompute the analytic display; playback has no autograd storage or version counters. Use the difference to explain why a backward rule must know which forward input it belongs to, not as a demonstration that live in-place mutation is safe.