- 1) Is there a branch here?
  - 2) If so, is it taken?
  - 3) If so, where to?

Of course, (1) and (3) are very important, so you pick your hashes to reduce aliasing to some low, but acceptable level. Otherwise you just have to eat mispredicts if you alias too much.

Note: (1) and (3) aren't really functions of history, they're functions of their static location in the binary (I'm simplifying a tad but whatever). You can more freely alias on (2), which is very history-dependent, because (1) will guard it.

The real value is that the easiest branch to predict is a never-taken branch. So if the compiler can turn a branch into a never-taken branch with the common path being straight line code, then you win big.

And it takes no space or effort to predict never taken branches.

That’s not really the problem.

The real issue is that VLIW requires branches to be strongly biased, statically, so a compiler can exploit them.

But in fact branches are very dynamic but trivially predicted by branch predictors, so branch predictors win.

Not to mention that even vliw cores use branch predictors, because the branch resolution latency is too long to wait for the branch outcome to be known.

I’m not up to speed on this stuff but I thought pihole only blocked the simplest stuff from devices that play nice?

I don't think that's true. My reading of that is "you lock in the price on your start date and can keep that for the next 2 years going forward". That doesn't help anybody joining at >$1k / share. :D (and that's only ESPP, not standard stock compensation).

It's a fundamentally impossible ask.

Compilers are being asked to look at a program (perhaps watch it run a sample set) and guess the bias of each branch to construct a most-likely 'trace' path through the program, and then generate STATIC code for that path.

But programs (and their branches) are not statically biased! So it simply doesn't work out for general-purpose codes.

However, programs are fairly predictable, which means a branch predictor can dynamically learn the program path and regurgitate it on command. And if the program changes phases, the branch predictor can re-learn the new program path very quickly.

Now if you wanted to couple a VLIW design with a dynamically re-executing compiler (dynamic binary translation), then sure, that can be made to work.

RISC-V consistently wins on L1i footprint.

The complaining is about number of dynamic instructions ("path length"), which can hit you if you don't fuse. Of course, path length might not actually be the bottleneck to raw performance, but it's an easy metric to argue, so a lot of people latch on to it.

> These are unacceptable bugs, showing a lack of architectural tests. It means no one ever ran those instructions and checked the result. The community should be able to fix this.

For BOOM it looks like the only 2 bugs found were miscounting on the inst-retired perf counter if software over-wrote it, and a fdiv.s/fsqrt.s that always listened to the dynamic rounding mode instead of the statically provided rounding mode, when specified. Not great, but recoverable.

> 1. Inaccurate instruction count when minstret is written by software

I don't know what that means, but having minstret written by software was definitely not something I ever tested. In general, perf counters are likely to be undertested.

> 2. Static rounding is ignored for fdiv.s and fsqrt.s

A mistake was made in only listening to the dynamic rounding mode for the fdiv/sqrt unit. This is one of those bugs that is trivially found if you test for it, but it turns out that no benchmarking ever cared about this and from all of the fuzzers I used when I worked on BOOM, NONE of them hit it (including commercial ones...). Ooops.

Fixed here: https://github.com/riscv-boom/riscv-boom/pull/629/files

I think RDNPC is what I was thinking of, but I can't at all remember what was perceived as "risky" about it. I may be overblowing something from memory. AUIPC is better anyways.

> "In addition, legacy integer instructions now can also use EVEX to encode a dedicated destination register operand – turning them into three-operand instructions and reducing the need for extra register move instructions."

Overall, APX is providing 10% fewer instructions, 10% fewer loads and more than 20% fewer stores.

Also adding pop2/push2 instructions for moving state faster.

And adding more powerful conditional instructions (loads/stores/compares) and flag-suppression.

Perhaps, although ARMv8 is fixed 4 bytes and x86-64 averages more than 4 bytes an instruction despite each x86 instruction mapping to more than 1.0 uops on average. Oops.

Conceivably, you could trap, look up something like the mvendor/march CSRs to triangulate CPUID, and Do the Right Thing, but you usually added a custom opcode because you believe your performance/use-case depends on it.

Basically, your Option #3: "don't distribute binaries with custom instructions." If it's so important, it should get pushed through the standards process and then the binaries can be portable.

This is different from "fixed-width SIMD" which has a hard-coded vector length. To make things more challenging for the programmer/compiler, I believe most x86 SIMD versions also don't provide a "mask" register, so you're stuck with using all vector elements (AVX512 added masks).

Each has its advantages and disadvantages (esp. on the design complexity vs programmer/compiler interface complexity).

RVV also provides a mechanism to reconfigure the register file, ganging logical registers together to get longer effective vector lengths.