Optimization ideas

• We need to cast pointers safely from i256 to register size ints when calling into runtime API methods. While in theory all pointers should be automatically in bounds, this assumption doesn't necessarily hold (as pointers / memory offsets are potentially untrusted user input). Safe truncation adds a lot of overhead in contract code; I tried to offload it into it's own function but on 32bit PolkaVM leads to even more code overall (because we have an i256 argument). On 64bit this could work though and if so we should use this optimization when compiling for size (-Oz).
• zbb instructions need to be implemented in PolkaVM. By experimentally switching the LLVM target to rv64 with+zbb significant changes in code size can be observed:

  ---- cases::tests::codesize stdout ----
  ERC20: 93072 bytes (change from 194140 bytes)
  Baseline: 63128 bytes (change from 131084 bytes)
  Flipper: 63688 bytes (change from 131796 bytes)
  Fibonacci: 63880 bytes (change from 133328 bytes)
  Computation: 65056 bytes (change from 135456 bytes)
  

• Investigate potential improvements of byte swaps, memset, memmove, mulmod, divs and the like
• Check all alignments, attributes etc. if they still make sense with our target
• Related: https://github.com/paritytech/revive/issues/62
• Pass YUL values as pointers instead of values to a) prevent loading from and spilling to stack back and forth b) use registers more efficiently

Start by reviewing the compiler's PolkaVM target handling and the codesize tests referenced in the issue, including the ERC20, Baseline, Flipper, Fibonacci, and Computation cases. Compare the remaining unchecked areas—byte swaps, memset, memmove, mulmod, divs, and YUL value passing—with the related issue #62. Done is not defined as one change; the selected optimization should have measured code-size or runtime benefits and preserve target correctness.