perf: add optimized llvm parameters for the zisk target

[benbencik]

Adds llvm-args to compiling a guest program for the ZisK target. The changes are based on work: Evaluating Compiler Optimization Impacts on zkVM Performance, and tuned to ZisK with the Optuna optimizer. More info in writeup Tuning compiler flags for zkVMs

The changes were benchmarked using zkevm-benchmark-workload on mainnet blocks 24949787 - 24949811, and the results show a consistent reduction of the AIR-costs by ~10%.

[han0110]

The result looks nice!

I'm thinking instead of hardcoding the flags, perhaps we could expose an env ERE_RUSTFLAGS for user to append these flags when necessary? For example:

let extra_rustflags = env::var("ERE_RUSTFLAGS").unwrap_or_default();
let rustflags = iter::empty()
    .chain(RUSTFLAGS.iter().copied())
    .chain(extra_rustflags.split_whitespace())
    .collect::<Vec<_>>();
let elf = CargoBuildCmd::new()
    .toolchain(ZISK_TOOLCHAIN)
    .rustflags(&rustflags)
    .features(&parse_cargo_features(args)?)
    .exec(guest_directory, ZISK_TARGET)?;

And in DockerizedCompiler we inherit the env ERE_RUSTFLAGS for users that use docker to compile

[benbencik]

Right, I agree that it should be possible to edit the arguments. For testing, I compiled with the flag CARGO_TARGET_RISCV64IMA_ZISK_ZKVM_ELF_RUSTFLAGS to apply the LLVM arguments. I would like to have hard-coded values set as defaults. Then, anyone can adjust or remove the defaults when running Docker. What do you think about that?

These specific numbers were optimized just for ZisK. If we wanted to provide arguments for other zkVMs, I could run the optimizer on them as well.

[han0110]

Right, I agree that it should be possible to edit the arguments. For testing, I compiled with the flag CARGO_TARGET_RISCV64IMA_ZISK_ZKVM_ELF_RUSTFLAGS to apply the LLVM arguments. I would like to have hard-coded values set as defaults. Then, anyone can adjust or remove the defaults when running Docker. What do you think about that?

A preset like this sounds good to me.

[benbencik]

Great, I added the flag. The LLVM parser always takes the last variant as valid.

[han0110]

Sorry I mean a env flag that enables this preset of llvm flags. Could these flags cause regressions in programs other than the Ethrex guest? If so I feel we shouldn't apply them by default.

When people want to enable this preset they can simply set an env and compile, and ERE_RUSTFLAGS still allows us to do fine tuning.

[Andrurachi]

Perhaps instead of a an env flag that enables this specific preset, it could be implemented as a named profile? For example, setting an environment variable like ERE_OPT_PROFILE=ethrex. That way, if we run Optuna for other workloads in the future, we can add new preset flags without cluttering the default toolchain avoiding possible regressions due to overfitting.

[benbencik]

Right, now I understand. I am not expecting two different guest programs to have the same optimum in the LLVM parameters. I like @Andrurachi's suggestion with different profiles. I will add that and keep the default flag empty.

[han0110]

LGTM!