What are the reasonable common rules (excluding branch prediction) to follow to please the BTBs of most modern and performant microarchitectures?

In other words: branch layout in one cache line.

(typical unreasonable for human):
- don't stack branches (one per decode byte set).
- branch as last instruction in cache line.

You mean a sequence of direct branch instructions is not the right way to implement an in-code jump table?

Do NOPs count as last instructions?

I think 1 or 2 branches in a row is okay - only seen performance hit on three in a row (in same decode).

All the references I see and testing show that NOPs are better at the start - speaking of loop alignment within cache lines. (Not talking about JMP.)

Is the performance loss of having "too many" branches in one cache line (querying the "BTB" starts to cost more) worth to read the resulting jump address from data memory and then to have only one branch instruction.

In other words, the over-querying of the "BTB" worth a data memory read instead (let's presume a L1 read).

Obviously, at some fanout perfect hashes and jump/call tables are the answer. At the low end it isn't a win - it's something that's engineered around.

The decode size is typically 16 bytes. We can get 8 branches in 16 bytes, but the typical pattern is some change in flags between - now we're down to 4 branches or less. So, the 1/2 limitation isn't as heavy a constraint as it seems. Unless you're an assembly programmer intentionally setting many flags and stacking branches.

Baw, I may change those in-code jump tables to data jump address tables since, indeed, most of the time they have a "perfect hash" (I'll prefetch the cache lines). I'll see some '-O3' code on C switch instruction when we don't have a magnificient hash.

If I understood not too badly, BTB on modern microarchitectures seems more constraint to the cache line size than to the decode size (based on what I read and understood about that).

I start to wonder if we should have CPU hints to declare that some branches should not be in the BTB (it seems microarchitecture designers say it's a very bad idea), namely all the time predicted using the static prediction rule of the microarchitecture (which is not the same on AMD and Intel/RISC-V). Why would it be a bad idea to reduce BTB pressure if we have semantic information on the usage of some branches... I guess they know better.

I am trying to avoid to have to try to uncrypt that logic from the SOGs.


EDIT:
had a look at some -O3(x86_64 generic) C switch, basically no more that 4 "stacked" branches, then it builds a 'gigantic' intermediary data memory based jump table (several cache lines) to jump to other mini blocks with with max 4 "stacked" branches.

It seems they are trying REALLY HARD to please the BTB.

EDIT:
It seems the "whatwg cartel" is still unable to completely gate the search and download of recent white papers on the BTB (good!), have some brain reading to do...