fix: aot traits

[Maillew]

Add starting code for AotTraits to handle x86 assembly generation.

Refer to design overview here: https://hackmd.io/iSSvk3HsQ0uDqS3i_9UyAA?both#AOT-Traits

[nyunyunyunyu]

We need assembles for the fallback operations anyway. Can we have a trait(AotFallback) for the fallback operations and generate a default implementation for structs implemented AotFallback? This will give us more flexibility if we want to override the implementation(e.g. a different way to preserve registers).

[Maillew]

sounds good, i can add this

[Maillew]

@nyunyunyunyu I think it may be a better idea to have the default implementations for fallback be feature-gated within the respective Executor and MeteredExecutor traits, instead of as a separate trait, since there shouldn't be a case where a struct has the AotFallback trait, but not the regular Executor trait, since the fallback requires the Executor trait to exist anyways

[nyunyunyunyu]

My thought is we could have something like this:

pub trait AotFallback: Executor + MeteredExecutor {}  
impl<F, E: AotFallback> AotExecutor for E {
  fn generate_x86_asm(&self, inst: &Instruction<F>) -> Result<String, AotError> {
    ...
  }
}

When you want a default implementation for an instruction X. You only need to:

impl AotFallback for X {}

[nyunyunyunyu]

Do we need pc to jump to a static label?

[Maillew]

we can discuss this with @GunaDD as well, but in the current example, extern_handler returns the updated PC value to register rax, and there is post-processing x86 assembly to determine where to jump next using the jump table. we can continue this convention that it should be on the onus of the generated x86 to write the next PC value to rax, and then it should be able to use any type of label

[nyunyunyunyu]

I think it means we need to read the jump table based on rax, which brings some extra overheads. If you know pc, for most jumps you can use only 1 instruction to jump into asm_run_pc_base_<pc>(sry the name might be inaccurate) at compile time.

[Maillew]

hm, if thats the case we can pivot so that this function is responsible for handling the updated PC value, and modify the fallback case that uses extern_handler to handle PC changes as well for consistency

[nyunyunyunyu]

Can you add a comment to show how generated ASMs look like and what the responsibility is? I feel we are not on the same page on that.

I supposed it generates:

balabala
call on_suspend
<exit if suspend>
<instruction execution logic>
<pc/context update>
<jump to next instruction>

@GunaDD mentioned the jump instruction for the dynamic case is:

    lea rdx, [rip + map_pc_base]
    movsxd rcx, [rdx + r13]
    add rcx, rdx
    jmp rcx

However if the jump point can be known at AOT compile time, we only need:

  jmp asm_execute_pc_<next_pc>

But we need to know the current PC in order to compute next_pc

[GunaDD]

Could you elaborate on how these traits will be integrated with the current create_assembly function in aot.rs?

[nyunyunyunyu]

Could you elaborate on how these traits will be integrated with the current create_assembly function in aot.rs?

@Maillew I think we have a working prototype here: https://github.com/openvm-org/openvm/blob/feat/aot-rv32-base-alu/crates/vm/src/arch/aot.rs Maybe let's integrate 1 RV32 instruction as an example?

[Maillew]

Could you elaborate on how these traits will be integrated with the current create_assembly function in aot.rs?

@Maillew I think we have a working prototype here: https://github.com/openvm-org/openvm/blob/feat/aot-rv32-base-alu/crates/vm/src/arch/aot.rs Maybe let's integrate 1 RV32 instruction as an example?

Yup, doing this rn

[nyunyunyunyu]

I'm confusing. Is this different from a/8?

[GunaDD]

yeah that is exactly equal to a/8, I felt like I wanted to be more clear about it but I could probably just do a/8 and write some comments to explain that

[nyunyunyunyu]

Return an error instead of panic because this is due to the user inputs.

[nyunyunyunyu]

Remove "dep:openvm-rv32im-transpiler"

[github-actions]

group	app.proof_time_ms	app.cycles	app.cells_used	leaf.proof_time_ms	leaf.cycles	leaf.cells_used
verify_fibair	238	322,610	2,058,654	-	-	-
fibonacci	990	1,500,209	2,100,402	-	-	-
regex	2,373	4,137,502	17,695,216	-	-	-
ecrecover	702	122,859	2,263,820	-	-	-
pairing	1,424	1,745,742	25,468,210	-	-	-

Commit: 26a24b5

Benchmark Workflow

[codspeed-hq]

CodSpeed Performance Report

Merging #2174 will degrade performances by 65.64%

_{Comparing feat/aot-traits (26a24b5) with feat/aot-lightweight-E1-rv32 (3181704)}

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

Summary

❌ 11 regressions
✅ 7 untouched
⏩ 42 skipped¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Mode	Benchmark	BASE	HEAD	Change
❌	WallTime	benchmark_execute[bubblesort]	232.8 ms	333.9 ms	-30.26%
❌	WallTime	benchmark_execute[fibonacci_iterative]	279 ms	400 ms	-30.25%
❌	WallTime	benchmark_execute[fibonacci_recursive]	379.2 ms	553.8 ms	-31.53%
❌	WallTime	benchmark_execute[keccak256]	251.4 ms	354 ms	-28.98%
❌	WallTime	benchmark_execute[pairing]	224.8 ms	276.9 ms	-18.82%
❌	WallTime	benchmark_execute[quicksort]	265.1 ms	373.8 ms	-29.06%
❌	WallTime	benchmark_execute[revm_snailtracer]	19.5 ms	56.6 ms	-65.64%
❌	WallTime	benchmark_execute[revm_transfer]	169.3 ms	292 ms	-42.04%
❌	WallTime	benchmark_execute[sha256]	249.7 ms	356.6 ms	-29.99%
❌	WallTime	benchmark_execute_metered[bubblesort]	276.6 ms	309 ms	-10.49%
❌	WallTime	benchmark_execute_metered[quicksort]	314.9 ms	352.6 ms	-10.7%

Footnotes

1. 42 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩