[Libre-soc-dev] v3.1B prefix

[Alexandre Oliva]

On Dec 13, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

> so, how did it come out? is it making sense and bringing numbers down
> to anything approaching "compelling"?

It doesn't look like we've got enough coverage to avoid canceling out a
significant fraction of the potential gains.  This is from the same gcc
driver I've been using since the beginning: 



32-bit uncompressed instructions: 109169
16-bit compressed instructions: 7732
16-imm compressed-mode instructions: 14509
10-bit compressed instructions: 4057

10-bit mode-switching nops: 3398
10-bit mode-switching nops for imm-16: 10821
16-bit mode-switching nops after imm-16: 1876

10-bit nop+16-imm pairs above, backtracked to 32-bit: 9171

Compressed size estimate: 521462
Original size: 541868
Compressed/original ratio: 0.962341

Nearly 20% of the instructions can be compressed, but right off the
start 1/3 of those are 16-imm ones that are both preceded and succeeded
by incompressible insns, i.e., they'd require explicit mode-switching
both before and after them.  Overall, 60% of the potential savings are
lost because of the need for explicit mode switching.  We just don't
have enough compressible insn density to get much better than
break-even.

If we discount the failed tentative 10-bit nop + 16-imm pairs, that
the compression estimator re-counts as backtracked to 32-bit, we'd get:

32-bit uncompressed instructions: 118340
16-bit compressed instructions: 7732
16-imm compressed-mode instructions: 5338
10-bit compressed instructions: 4057

10-bit mode-switching nops: 3398
10-bit mode-switching nops for imm-16: 1650
16-bit mode-switching nops after imm-16: 1876

i.e., 12.5% of compressed insns, but with an overhead of 5% of the
whole, or 40% of the savings.

Interestingly, the overhead of forced mode switching insns on account of
16-imm insns is slightly bigger than that of other 16-bit insns, though
there are some 40% more of the latter.  This may seem puzzling,
considering that the 16-imm insns are more common.  Indeed, once we
count again the 9171 ones that would be worse than break-even to encode
in compressed mode, we get 16-imm twice as often as other 16-bit insns.
But then again, there are too many uncompressible insns among them to
make the mode switching worth it.

My hunch is that we'd have to more than double the percentage of
compressible insns to make compressed mode shine.  50%-60% of the total
insns would reduce very significantly the mode-switching overhead
(making switch back after one insn a lot more prevalent and useful), so
we'd get most of the 25% to 30% compression ratio this would max out at
(vs 4% compression out of 20% of compressible insns, as today)

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist         GNU Toolchain Engineer
        Vim, Vi, Voltei pro Emacs -- GNUlius Caesar