> E.g. you fetch 66 bytes instead of 64

Not really, you would fetch fewer bytes with RVC [2, page 9], because the code density is better.

> I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned.

This is very hard to quantify.

> Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).

I've liked the back and forth slides bellow. Though I want to bring up to things regrading the Qualcomm slides:

    > [RVC] Performance benefit is modest
    > • Best case: 2-3% speedup

I recently benchmark compiling programs with a rva23 clang build and clang compiled for rva23-without-C and got a 10% performance improvement from RVC on the SpacemiT X100.

I also have no idea how they got those numbers. (not that they are wildly implausible, it's just not transparent)

    > Improving Android Code Size

In the last presentation they show how you can add a +-64M 32-bit long jump instruction to improve codesize in large binaries, like those in android.

I want to point out, that the JAL opcode has enough space left (7/8th) to encode a long jump of a same range and there is a proposal for a 32-bit +32M -12M 32-bit long jump: https://github.com/riscv/riscv-isa-manual/blob/zijfal/src/un...

[1] https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%2...

[2] https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS...

[3] https://lists.riscv.org/g/tech-profiles/attachment/378/0/Res...

[4] https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...