[Rafael-SOWNet]

Part of #2195.

Both compilers now compute only the case a piecewise or a provided takes. #2209 made FastExpression compile them, but without a jump: it computed every case and kept the one that held. The LINQ compiler did the same in effect, because BuildTree assigns every node to a local before the expression's value, so its conditional only chose between cases already computed. No value was wrong, since no kernel throws. The cost was the untaken case's: piecewise(primepi(x) provided x < 100, 0) at 9999991 built a 625 KB sieve on every call.

	FastExpression	LINQ Complex	evaluation
that expression at 9999991, master	17,769 µs	18,173 µs	13 µs
the same, this branch	0.26 µs	0.03 µs
a mobius(x) case not taken, at 999999999999989, master → branch	882 → 0.24 µs	870 → 0.03 µs
a piecewise of 20 cases, master → branch	8.3 → 0.45 µs	1.9 → 0.06 µs

These are single runs, but the ratios are large. On an expression with no branch, x + x/2 + sin(x), FastExpression is within noise: 41.3 / 41.9 ns on master and 37.6 / 41.4 ns here, best of 7 rounds, interleaved.

FastExpression gets two forward jumps:

• JUMP_UNLESS_HOLDS pops a truth value and jumps unless it is exactly true, so an undecided predicate passes the case over, as evaluation does.
• JUMP goes to the end.

Each case compiles as its predicate, a jump to the next case unless it holds, its value, then a jump to the end. PUSH NaN follows the last case. Every jump goes forward, so a call always ends.

The subexpression cache needed care:

• A jump can skip the instruction that saves a repeated subexpression, and a later read would then return the previous call's value. The compiler logs every save and, after code a jump may skip, marks what it saved as unsaved, so the next occurrence recomputes.
• What a predicate saves stays valid for the cases after it, since they are reached only once it has run.
• Switching that off makes the tests catch three stale values: piecewise(sin(x) provided x > 1, sin(x)+1 provided x > 0, sin(x)+2) at 1/2 gave 1.909, where the value is 1.479.

The LINQ compiler builds each case's value, and each predicate after the first, as its own block inside the conditional, with a copy of the cache. That is the second commit, kept apart.

No answer changes. compilecheck's tables are identical before and after, and the new agreement tests passed on master before the change, so no BREAKING-CHANGES.md row is owed.

What #2195 still holds:

• gamma(a, z) stays refused, as its thread decided.
• gcd and lcm at whole arguments, and whether Compile should evaluate calculus nodes first, are maintainer decisions.
• and / or still compute both sides; Kleene's tables would allow the same jump.

Checked on this branch:

• Tests: UnitTests 19492 passed, plus the MCP, Terminal, InteractiveWrapper and F# wrapper suites, and the AOT smoke test, which has a check that compiles a piecewise whose cases are blocks. The new BranchNotTakenCompilationTest checks 13 expressions against evaluation at real, negative, zero, complex and NaN points, visited in both orders, in FastExpression and in LINQ over Complex and double. It also asserts that a call at a point where a case is not taken allocates under 64 KB; on master that fails 8 of 8. After rebasing onto Compile a function of a matrix argument as the function of each entry, and vectors as arrays #2435, the compile, matrix and public-API tests pass (1576).
• Harnesses: BoundCheck, RootCheck, CasBench, PropCheck, SimpSweep, RuleCheck, CanonCheck and Confluence all pass. limitcheck is not run, since nothing here touches limits.

🤖 Generated with Claude Code