They have this example for general signed overflow checking in the 2.2 spec (but I'm not sure if this counts as a recommended sequence for fusion):

    add t0, t1, t2
    slti t3, t2, 0
    slt t4, t0, t1
    bne t3, t4, overflow

So two extra registers needed also..

edit: so I now think a good extension to add overflow checking to RISC-V is with an instruction that works like "slt"- call it "sov", set if add would overflow:

    add t0, t1, t2
    sov t3, t1, t2
    bnez t3, overflow

add/sov could be fused..

Fusing that would be very difficult, since it's hard to write that many registers with a single op, and I don't think they recommend it. This does mean signed overflow checking will be comparatively expensive. But thanks for the reference, I agree this is a weak point :).

You don't have to use real registers in a single op. Fusing means interpreting a pattern in the input stream and issuing a different instruction from a richer microarchitectural instruction set

You have to preserve the architectural registers at the end of the sequence. So if there are 5 registers, you either have to have a 5-register microinstruction, or issue multiple 3-register microinstructions instead.

You have to preserve architectural registers only when some other instruction actually depends on them. When you detect a dependency you lazily compute their content (causing a stall)

The dependency could be arbitrarily many millions of instructions away.

The only way to know there isn't a dependency is if that register gets clobbered by something else very soon afterwards.

But this whole topic of "checking for signed overflow is expensive" is overblown. It's simply not that important an operation, especially in the context of those languages that do it a lot also doing a lot of memory references, which are far more expensive.

Adding arbitrary completely unknown integers is pretty rare. If you know both numbers are greater than zero then a single compare-and-branch is all you need. If one of the numbers is a constant then a single compare-and-branch is all you need.

That sounds like an amazingly bad idea, because you would instead have to retain the two source registers until you can prove that you don't need the two output registers anymore, which can be arbitrarily far in the future.

At least in their papers and mailing list discussion, the limit for simple fusion is not on the number of source operands, but on the number of destination operands. A classic example is a PC-relative long jump:

  auipc lr, zero, .LONG_TARGET20
  jalr  lr, lr, .LONG_TARGET12

Only one register (the link register) is clobbered, so the pair can be fused into a single wide jump-and-link.

So in parent's example, sov might fuse with the following bnez, but it likely wouldn't fuse with the preceding addition.

Yes, I missed the edit, I was only commenting on the first part.

Quite a few things determine whether a fusion is doable or not. In addition to the number of destination registers, you do, to a more relaxed extent, care about source operands, but also things like ‘does this fit nicely in a single pass through the pipeline?’ and even just ‘is this materially beneficial?’

Lots of cores (but not all) can write two registers from a fused instruction, given the right conditions, and sov does rerun the addition, so add-sov fusion sounds very doable to me.

rotate-and-xor (and xor-and-rotate) are both common operations in ARX ciphers. They demand 4 macro-ops in RISC-V, but only one in ARMv8.

Bitfield insertion is only one instruction in most RISC ISAs, but 5 or more in RISC-V.

The (unfinalized) bitmanip extension has single-op rotates.

I really don't like it. It seems like they copied x86 (bext, bdep) where they should have been plagiarizing armv8 (BFM, ...).

I've watched that extension's development since it was little more than one smart guy's wish list. I don't think its fair to say that they copied any one architecture. The authors have put in a ton of time researching the tradeoffs and investigating the trade space over the years.

That said, until it gets ratified by the consortium and implemented in silicon its still just a (well-researched) wishlist.

I’d have to reinvestigate more than I feel like doing right now so I’ll tell you where to look.

You need fast sequences for all of these variants:

- add or sub or mul

- signed or unsigned

- 32 bit or 64 bit

Some of those need 5 instructions. I don’t remember which adventure you need to pick to get 5.

Thanks for the reply but I'm not sure what you mean. Are you saying you want to add an i32 to a u64? Or am I completely misunderstanding? I'm not sure why unsigned-unsigned or signed-signed instructions would be hard. Idk about mixed sign operations, but when do they ever occur without first casting one to the other?

I mean you will do overflow checks on the following. I’ll use the “s” and “u” prefixes to mean signed and unsigned. Unsigned matters less than signed.

sadd32, sadd64, uadd32, uadd64, ssub32, ssub64, usub32, usub64, smul32, smul64, umul32, umul64

Ah, I get you now. Yes, this looks like a weak point, and I totally get why it'd screw with Javascript optimizations.

I don't think it's a fusion problem; even if you did fuse these sequences, they'd still be bad, since they'd be writing lots of extra registers.

Yeah exactly!

And worth noting that these are just the ones where you usually have good sequences on other cpus, but even then (like signed mul) they’re not perfect. Lots of room for improvement. It’s just that risc-v didn’t seize the opportunity.