Optimize Int256 negativity-only gates

[kamilchodola]

Results

The signed operations the EVM reaches for - SDIV, SMOD, SAR, SLT, SGT - against main, in ns per
operation. x64 is a Ryzen 9 9950X (Zen 5, AVX-512) under Tier-1 with dynamic PGO; ARM64 is the
ubuntu-24.04-arm runner (Neoverse N2) through the benchmark workflow. Operands are 32-byte aligned on
both, and SignedOpsBench in this PR is what produces the ARM column.

Operation	x64: main -> PR		ARM64: main -> PR
SAR, negative value	4.99-5.56 -> 0.95-0.99	0.18	5.58 -> 2.71	0.49
SAR, mixed signs	3.22-3.38 -> 0.99-1.03	0.29-0.32	4.66 -> 2.71	0.58
SAR, positive value	1.52-1.80 -> 0.96-0.99	0.55-0.63	3.63 -> 2.71	0.75
SAR by a constant 1	1.80 -> 0.99	0.55	2.80-4.22 -> 2.03	0.48-0.73
SLT, SGT (CompareTo)	1.20-1.41 -> 0.63-0.65	0.46-0.53	2.27-2.39 -> 1.55-1.58	0.65-0.70
operator <	1.06-1.26 -> 0.68	0.54-0.64	1.84-1.91 -> 1.61-1.62	0.85-0.88
Signed multiply, mixed signs	7.17-8.87 -> 4.90-5.76	0.65-0.68	20.1-20.2 -> 8.17	0.40-0.41
Signed multiply, positive	5.23 -> 4.91	0.94	12.36 -> 8.17	0.66
SMOD	8.91-11.78 -> 8.57-10.35	0.88-0.98	22.6-44.8 -> 22.1-33.2	0.74-0.98
SDIV	8.04-14.29 -> 7.86-14.58	0.98-1.02	18.9-29.0 -> 18.7-27.9	0.96-0.99
Neg (unchanged code, control)	0.63 -> 0.63	1.00	3.097 -> 3.097	1.000

SAR now costs the same regardless of the sign of the value or where the count falls, where it used to
cost 3.7x more for a negative value than a positive one. Nothing regresses on either platform.

What is in it

Two parts. The original change routes the negativity-only gates through IsNegative instead of Sign,
which drops an IsZero test - a 256-bit compare - from every gate that only wanted the sign bit. On top
of that:

• Truncated signed multiplication needs no sign handling at all. Negation is exact in Z/2^256, so
  with the sign applied as modular negation |x|*|y| = s_a*s_b*x*y, and multiplying by s_a*s_b again
  returns x*y: the product of the raw words is already the signed product, Int256.Min included. The
  old code negated both operands, multiplied the magnitudes and negated the result. Exp inherits it,
  keeping only its negative-exponent check.
• One funnel for the arithmetic shift. It ran two implementations: a non-negative value went to
  UInt256.Rsh, a negative one took an n % 64 == 0 switch, three Srsh64/128/192 helpers that each
  wrote a full Int256 the caller then re-read limb by limb, a goto ladder, and One.Neg for the
  saturating counts - eleven basic blocks and four calls for a shift. The sign is the only thing the two
  cases disagree about and it is exactly what the funnel shifts in from above, so one funnel covers both,
  count for count.
• The shift stays in vector registers. Computing four limbs in general registers and handing them to
  the 32-byte store costs four domain crossings (vmovq 5 cycles, vpinsrq 6); 25 of the method's
  instructions were that. The operand is already 32 contiguous bytes, so it loads as one vector: the word
  shift is a lane permute from a small window table, the bit funnel two shifts and an OR, the sign fill a
  vpcmpgtq plus vpermq. AVX-512VL does the window in one vpermt2q per source, taking a lane of the
  fill for any index past the top limb; AVX2 uses vpermd and selects the vacated lanes from the fill
  afterwards. Crossings per method 25 -> 7, and 2 on the hot path. Everything without 256-bit vectors -
  no AVX2, no intrinsics, and ARM64 - keeps the scalar funnel, which also got cheaper: an arithmetic
  shift of the top limb is that limb's funnel step with the sign already in it, one instruction instead
  of three.
• The compares make one descending pass. CompareTo asked two questions to answer one:
  this < b ? -1 : Equals(b) ? 0 : 1 runs the ordering test and then a full 256-bit equality test
  whenever the answer is not "less" - and SLT and SGT go through exactly this to read one bit of the
  result. The sign lives in the top limb, so comparing that limb signed and the rest unsigned is
  two's-complement order: one pass, stopping at the first limb that differs, and no sign-class branch in
  operator < either.

Int256.cs ends up 418 lines changed and shorter than it started. Public API and semantics are
unchanged, with one documented exception: a negative shift count, which no caller passes, moves from
per-limb garbage to the unsigned type's documented rule.

How it was measured

Two independent harnesses, because they disagreed twice and each time the disagreement was real:

• Decided under Tier-1 with dynamic PGO, not FullOpts. Four further changes - a limb-wise ~x + 1
  negate, a Divide/Mod restructure, a MultiplyMod fold, a branchless Sign - measured 0.72-0.94 with
  tiering off and 1.04-2.36 with it on. PGO keeps UInt256.Subtract(0, x) in vector registers end to
  end at 0.65 ns, where the limb form has the shorter carry chain but has to gather four registers into
  the 32-byte result. All four were dropped; only what wins in the configuration that ships is here.
• Operands staged 32-byte aligned. A 4096-element operand array is large enough for the LOH, which
  put it at 0, 8, 16 and 24 mod 32 across shapes in one process; an unaligned 32-byte read splits a cache
  line half the time, and that bias was large enough on its own to invert a copy-versus-by-reference
  comparison. SignedOpsBench stages into pinned aligned buffers for the same reason.
• A control in every run. Neg is untouched by this PR, so it reads 1.000 on ARM and 1.00 on x64;
  when a row moved without a code change - one ARM pair had Mod at 1.16 and the next at 0.79, with the
  base drifting 32% between runs on identical code - the control is what said to re-run rather than
  report it. Every ARM number above is from a repeated dispatch pair.

Writing a non-inlined callee's result straight through the out parameter also measured 1.07-1.25 and is
not used here: the JIT cannot prove the parameter does not alias the operands, while the copy through a
local it can prove is free.

Validation

• Full suite in five configurations: default 587,686, AVX2-only 587,686, no-AVX2 587,686,
  DOTNET_EnableHWIntrinsic=0 587,685 with the one expected hardware-hash skip, and
  -p:EnableZkEvm=true 587,683. The first three each exercise a different one of the shift's three paths.
• The 258-count shift sweep over the signed boundary set covers both shift paths; the added test pins the
  limbs the shift vacates, which is the part a zero fill would get wrong, and it was verified to fail with
  fill = 0.
• git diff --check clean.

Not taken

With no AVX2 and no NEON - the portable fallback, where there is no 32-byte store to hide the funnel
behind - a count that is an exact multiple of 64 costs 1.40x, because the old code answered those with
limb moves and no shifts. A bitShift == 0 fast path recovers it to 1.32 but costs the common
mixed-count case in that same configuration 0.805 -> 0.840, so it is not worth taking; every other shape
there is 0.68-0.95.

AddMod and SubtractMod keep their structure: their mixed-sign arm adds exactly, since opposite signs
cannot overflow, and then reduces signed, which the magnitude form cannot express, and no caller in
Nethermind uses either.

Two follow-ups belong in the consuming repo rather than here: SLT and SGT call CompareTo(...) < 0 and
> 0, which materialises a three-way answer to ask a two-way question, and SAR's count >= 256 guard uses
.Sign >= 0 where !IsNegative is the same test without the zero check.

[LukaszRozmej]

Review

Verdict: approve. Every gate rewrite is provably equivalent, the public API is untouched, and CI is green on all 13 matrices (incl. NoHWIntrinsics and ARM). I also ran the two new tests locally in a worktree: 26/26 pass.

Correctness — checked each rewrite

The load-bearing identity: Sign is IsZero ? 0 : u3 < 2^63 ? 1 : -1, so Sign < 0 <=> u3 >= 2^63 <=> (long)u3 < 0. The IsZero short-circuit is dead weight for a negativity test because u3 >= 2^63 already implies non-zero. The new IsNegative is exact, not approximate — that's what makes the rest mechanical.

• Multiply: (aSign<0 && bSign<0) || (aSign>=0 && bSign>=0) == aIsNegative == bIsNegative ✔
• MultiplyMod: (x<0 && y>=0) || (x>=0 && y<0) == xIsNegative != yIsNegative ✔
• ExpMod: exp < Zero == exp.IsNegative (operator < is two's-complement signed) ✔; mAbs.Sign < 0 -> m.IsNegative is fine since mAbs is an unmodified copy of m at that point ✔
• Divide: hoisting both IsNegative reads above the branches is aliasing-safe — every path writes res only after its last read of n/d, so Divide(in a, in b, out b) behaves as before ✔
• Mod, Rsh, AddMod, SubtractMod: direct substitutions ✔

Boundary math in the new test also checks out by hand (min/-1 -> min, min*min -> 0, ExpMod with m = -2^255 works because Neg(min)._value == 2^255 is the correct unsigned magnitude).

Findings

1. The boundary coverage belongs in the shared case sources, not a bespoke test. This is the one I'd push on. I probed the existing corpus: UnaryOps.SignedTestCases has 22 values, of which exactly 2 are negative — TestNumbers.Int256Min plus one of the five RandomSigned(0) draws (seed 0 yields +, +, +, -, +; verified by running it). And TestNumbers.Int256Min = -Int256Max = -(2^255 - 1) is not the true minimum: -2^255 was never exercised by any signed test before this PR. Likewise TernaryOps.SignedModTestCases filters Item3 >= 0, which is why negative moduli were uncovered.

So the gap you found is real, but fixing it at the source — add -(BigInteger.One << 255) to SignedTestCases, relax the modulus filter — extends it to all ~12 signed operations through the existing template, rather than to the hand-picked subset re-implemented in the new test. Cost is ~14% more ternary cases on a suite that runs in under 2 min. (Relaxing the modulus filter needs the template oracle checked first, so that part may be a separate PR.)

2. NegativityGatedOperations_MatchBigInteger is a 90-line grab-bag. It asserts ~10 operations plus four exception contracts in one test. A failure gives you one red test and a because string to decode, and it can't be filtered or parallelized per-op. At minimum, split the throw assertions (divide/mod by zero, negative exponent) out of a test named *MatchBigInteger*, and prefer [TestCaseSource] over nested foreach per the repo's test guidance.

3. Coverage gap inside the new test. if (a < -17 || a > 17) continue; sits before the AddMod/SubtractMod/MultiplyMod block, and the follow-up values × values loop only calls AssertMultiplyDivideAndMod. So the three mod operations — whose gates this PR changes — are never exercised with x/y at ±2^255. That's the interesting case precisely because Neg(MinValue) == MinValue. Worth extending the second loop to cover them.

4. operator < now duplicates IsNegative. It open-codes unchecked((long)z._value.u3) < 0 twice, with the comment that explains the trick. Now that IsNegative is that expression, use z.IsNegative / x.IsNegative there.

5. Two negativity-only gates were missed. Abs() (if (Sign >= 0)) and Convert(out BigInteger) (if (Sign < 0)). Neither is hot — Abs is only reached from Convert — but converting them makes "no negativity-only Sign gates remain" actually true.

6. Follow-up (not this PR): AddMod/SubtractMod don't actually need three-way Sign. The description says zero-vs-positive changes control flow there, but working through all the zero cases, it doesn't: routing a zero operand into the IsNegative-based branch gives the same answer every time (0 AddMod y == (0+y) mod m; for SubtractMod with y == 0, -(|x| mod m) == x mod m under truncated division). Both could drop Sign entirely — but add explicit zero-operand cases to the corpus first.

7. The perf claim isn't reproducible from the repo. Deleting the temp harness was right, but the permanent benchmarks can't stand in for it: SignedBenchmarkBase.Values is { Int256Max, RandomSigned(1) }, and RandomSigned(1) at seed 0 is positive — so DivideSigned/RightShiftSigned/MultiplySigned never take a negative branch. There's also no ModSigned benchmark at all, despite Mod being the largest reported win (-9.9% ARM). Adding one negative value to SignedBenchmarkBase.Values plus a ModSigned class would make the numbers re-derivable later. Not a merge blocker.

On the measurement write-up

Good discipline — flagging the AMD control drift as not attribution-safe, and reporting the RPC corpus as neutral rather than spinning it, is the right way to present a library-level micro-optimization.