> On the other hand, if you want to fuse load pair on RISC-V you have the entire rename stage to figure out which uops can be fused independently of the rename stage

That's a good point.

If some RISC-V μarch was going to invest the extra gates for a complex fusion setup, the search isn't actually going to slow anything down, as it can run in parallel with other frontend operations (like renaming).

I always just assumed fusion was done as early as possible, only considering instructions that are right next to each-other (that's certainly the intent of the RISC-V spec), and then resolved immediately after decode.

But maybe it's better to do it right at the end of the front end; After renaming, during insertion into the scheduler.

You shouldn't be sharing that.

Despite my curiosity, I explicitly refused to agree to Apples terms for accessing those documents, because they were very draconian. The terms absolutely forbids using the information for anything other than optimising software for apple devices.

Discussing the design tradeoffs of RISC-V μarches couldn't be further from "optimising software for apple's devices".