In https://news.ycombinator.com/item?id=29444322 "ruslan" links the original macro-op fusion stuff from 02016: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu... and https://arxiv.org/abs/1607.02318. Surprisingly, those present "shootout" results that are really just "effective dynamic instruction" counts and "dynamic byte" counts, ending in a "design proposal"; they don't seem to have simulated macro-op fusion at RTL level, much less in an FPGA or a MOSIS run.
I think macro-op fusion (with a few exceptions) is useful only on a narrow set of mid-range cores. High end cores want to split everything up (RISC-V comes pre-split), while low end cores want to use as little hardware as possible.
There are a few exceptions, for example combining a LUI or AUIPC into a full 32 bit constant with the following instruction(s). There is a full 32 bits for that data path already, so that has zero effect on the back end (except just removing an instruction). SLLI/{SRLI,SRAI} pairs is probably another.
Yes but a high-end core does not necessarily splits instruction the same way as RISC-V does.
For instance an indexed store:
RISC-V ISA splits it into an ADD+STORE pattern which may be recognized by macro-op fusion, while a high-end core splits it into a store_address uop (that compute the effective address and update the address field into the store-buffer entry) and a store_data uop (that update the data field into the store-buffer entry, and this uop is "address agnostic")
Macro-op fusion (alone) does not only reduce the number of uop, it could also reduces physical register usage as intermediate results are not stored into physical registers.
For instance, the indexed load pattern (ADD+LOAD) without macro-op fusion needs:
- 2 physical registers in read;
- 2 physical registers in write (one per macro-op), meaning that 2 physical registers will be allocated.
While the macro-op fused version needs:
- 2 physical registers in read;
- 1 physical register in write, meaning that a single physical register will be allocated.
There are more macro-op fusion suggestions for RISC-V precisely because RV instructions are simple. This gives more opportunity for macro-op fusion.
> so it's not clear if this is even feasible
What macro-op-fusion are you talking about exactly? Most of the macro-op-fusion suggested are quite trivial and have already been implemented
In which chips, and how much of a win are they?
I can't say if the macro-op fusion will be enough to beat ARM & x86, but I can tell it's feasible.
Clearly macro-op fusion is a computable transformation of the instruction stream, so macro-op fusion is certainly feasible. I think what Jha was questioning was whether catching up to ARM is feasible if your main weapon is macro-op fusion. The Celio/Dabbelt/Patterson/Asanović tech report I linked yesterday shows that it's promising, but it's been six years and I'd like to know if that's actually being tried and how well it works.
Bruce Hoult's comment from a few months ago suggests that it wasn't really being tried at SiFive, but he left SiFive a couple years ago and might be out of date, and the Honey Badger designs are potentially a whole new ballgame.
I don't think so, there are indeed unrealistic macro-op fusion patterns that can reasonably be described as "unfeasible" or "unrealistic".
But macro-op fusion patterns suggested in the RISC-V spec, papers about macro-op fusion on RISC-V, and the SiFive patent on macro-op fusion are realistic and feasible.
> Bruce Hoult's comment from a few months ago suggests that it wasn't really being tried at SiFive
Commits from SiFive people's in GCC [1] suggest that short-forward-branch macro-op fusion patterns are recognized by SiFive hardware.
I don't know if they recognize other macro-op fusion patterns.
But SiFive has a bunch of stuff to improve before diving into macro-op fusion.
[1]: https://patchwork.ozlabs.org/project/gcc/patch/2019043023474...