perf(evm): optimize interpreter dispatch with computed goto and opcode inlining

[starwarfan]

Replace the switch-based opcode dispatch in the interpreter fast path with computed goto (GCC/Clang __label__ extension) for better branch prediction and reduced dispatch overhead.

Key changes:

• Add computed goto dispatch table (256 entries) with per-opcode label targets
• Inline hot opcode logic directly in dispatch targets: arithmetic (ADD, SUB, MUL, DIV, etc.), logic (AND, OR, XOR, NOT), comparison (LT, GT, EQ, etc.), shifts (SHL, SHR, SAR), stack ops (PUSH0-32, DUP1-16, SWAP1-16, POP), and control flow (JUMP, JUMPI, JUMPDEST)
• Use local variables (Pc, sp) for program counter and stack pointer to encourage register allocation, syncing back to frame only for complex handlers
• Delegate complex opcodes (memory, storage, calls, creates, logs) to existing handler implementations via HANDLER_CALL macro
• Retain original switch-based dispatch as fallback for non-GCC compilers (#else)

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

• N
• Y

2. What is the scope of this PR (e.g. component or file name):

evm, interpreter

3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):

• Affects user behaviors
• Contains CI/CD configuration changes
• Contains documentation changes
• Contains experimental features
• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Other

The EVM interpreter's main dispatch loop uses a switch statement over 256 opcode values. Modern CPUs struggle to predict indirect branches from large switch tables, causing pipeline stalls on every opcode dispatch. This PR replaces the switch with GCC/Clang computed goto (&&label / goto *dispatch_table[opcode]), which gives each opcode its own indirect branch site and allows the branch predictor to specialize per-opcode.

Dispatch mechanism: A 256-entry dispatch_table maps each opcode to a label address. After executing an opcode, the code jumps directly to the next handler via goto *dispatch_table[*Pc] without returning to a central switch.

Opcode inlining: Hot opcodes (arithmetic, logic, comparison, shifts, stack manipulation, control flow) are inlined directly in their dispatch targets with local Pc/sp variables to encourage register allocation. Complex opcodes (memory, storage, calls, creates, logs) delegate to existing handler methods via a HANDLER_CALL macro that syncs local state before/after the call.

Portability: The computed goto path is guarded by #if defined(__GNUC__) || defined(__clang__). A fallback #else branch retains the original switch-based dispatch for non-GCC compilers.

Benchmark results (evmone-bench, Release mode, vs evmone baseline interpreter):

• 165 of 167 synth tests faster than evmone baseline
• Average speedup: 5.25x (excluding loop/startup tests)
• Peak speedups: MUL 8.2x, SUB 8.1x, ISZERO/NOT 7.9x, SWAP 6.9x, ADD 6.0x
• Only loop_v1/v2 (tiny 5.8k gas) remain slower due to per-call overhead

4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):

• N
• Y

5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:

• Unit test
• Integration test
• Benchmark (add benchmark stats below)
• Manual test (add detailed scripts or steps below)
• Other

Benchmark results using evmone-bench (Release mode, vs evmone baseline interpreter):

• 165 of 167 synth tests faster than evmone baseline
• Average speedup: 5.25x (excluding loop/startup tests)
• Peak speedups: MUL 8.2x, SUB 8.1x, ISZERO/NOT 7.9x, SWAP 6.9x, ADD 6.0x
• Only loop_v1/v2 (tiny 5.8k gas) remain slower due to per-call overhead

6. Release note

perf(evm): replace switch-based interpreter dispatch with computed goto (GCC/Clang), inlining hot opcodes for ~5.25x average speedup over evmone baseline on synthetic benchmarks.

Made with Cursor

[Copilot]

Pull request overview

This PR optimizes the EVM interpreter’s gas-chunk (“no gas per opcode”) fast path by replacing the switch-based opcode dispatch with GCC/Clang computed-goto, inlining hot opcodes and delegating complex ones to existing handlers.

Changes:

• Adds a computed-goto dispatch table (256 entries) and a new dispatch loop using local Pc / sp.
• Inlines selected hot opcodes (arithmetic, stack ops, and control flow) directly in dispatch targets.
• Delegates complex opcodes (memory/storage/env/call/create/log/return/revert/selfdestruct) to existing *Handler::doExecute() via a helper macro, retaining the switch-based chunk dispatcher as fallback.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

TARGET_PUSH0 doesn’t guard on Revision, and the computed-goto path doesn’t perform the NamesTable-based undefined-opcode check that the switch fast path relies on. This changes semantics for pre-Shanghai revisions where opcode 0x5f must be treated as EVMC_UNDEFINED_INSTRUCTION, not executed as PUSH0.

[Copilot]

cgoto_table is initialized via a non-atomic static bool cgoto_initialized check. If BaseInterpreter::interpret() can be entered concurrently, this is a data race (undefined behavior) and could also leave the table partially initialized. Prefer thread-safe initialization (e.g., a function-local static table built by a lambda, or std::once_flag/std::call_once).

[Copilot]

The computed-goto fast path bypasses the existing NamesTable[Op] == NULL check used in the switch-based chunk dispatcher to enforce revision-specific opcode availability. As a result, opcodes introduced in later revisions (e.g. PUSH0/TLOAD/TSTORE/MCOPY/BLOB* etc.) can be executed in earlier revisions instead of raising EVMC_UNDEFINED_INSTRUCTION. Consider adding an opcode-availability check in the dispatch path (initial + DISPATCH_NEXT), or building a dispatch table per Revision that maps unsupported opcodes to TARGET_UNDEFINED.