[PATCH] D32564: AArch64: compress jump tables to minimum size needed to reach destinations

[Tim Northover via llvm-commits]

> Well, dealing with the large code model has pretty much the same
> constraints, so it is effectively something the code has to support
> anyway. How does ARM deal with very large local branches? I.e. if you
> have a 1GB function and a branch from the beginning to near the end?

There's a difference between supporting >4GB process map and
supporting a single function that's >4GB. I think things would quickly
go wrong throughout LLVM if you tried the latter (-fPIC -mcmodel=large
already assumes 32-bit jump tables).

But for semi-reasonable functions BranchRelaxation will split basic
blocks as necessary to make branches work. It doesn't handle external
calls AFAIR, which effectively puts an existing 128MB limit on
functions (which we haven't hit yet to my knowledge).

> Helpful in the sense of allowing better addressing. It's not just the
> entries in the jump table that can be potentially compressed, but the
> load of the jump table address itself might now fit as small immediate +
> pc. On most architectures I would expect a clean up pass would work,
> i.e. emit the function itself with pseudo-relocations and once you know
> the function size, the encoding of the jump table can be decided.
> Afterwards the relocations are adjusted as fixup. The generic access
> case often requires a register more, but that might be the price to pay?

The implementation wouldn't be too bad there, just make this pass use
a slightly different annotation data if the table is going to be
within 1MB (I said 128MB before, but I was confusing it with the
maximum branch distance).

But we're back to motivation. I wouldn't really want it on by default
because of the potential security issues (and general cleanliness:
it's .rodata, not code); and I wouldn't want a Clang option because we
don't want to encourage people to use compiler-specific
micro-optimization tuning flags like that (and, realistically, very
few would).

Cheers.

Tim.