AArch64: High level review

Tim Northover t.p.northover at gmail.com
Tue Feb 5 11:40:19 PST 2013


Hi Jim,

Thanks for your comments. I'm applying most of them, and thinking a
bit more about that PostEncoderMethod thing. The assembly diagnostics
change looks particularly promising (modulo the usual, unavoidable
issues of the assembler misinterpreting which category of instruction
you actually wanted).

> LR and FP should be explicitly called out as being "special" in their register names, in particular for printing.

That's getting dangerously close to violating "canonical disassembly".
I think we'll probably have an official position on whether that's
"allowed" (it definitely came up when we were discussing
pseudo-instructions). Notably, gas doesn't even support them as
aliases yet as far as I can tell, which may cause problems.

> I would strongly consider getting rid of the constant island pass.

This is a little worrying. There'd be substantial simplification of
LLVM -- I delayed implementing it as long as possible for that reason
(until the dreaded ch7_22 died at link-time).

But there's a bit of a worrying execution penalty. Currently we use
the special "load literal" instructions, which have a fairly large
pc-relative range (+/- 1MB). If literals are in another section we'll
have to use an adrp/ldr pair. Probably not much overhead on high-power
processors, but non-zero.

It's even worse in the (admittedly unimplemented and specialist) large
memory model, where a movz/movk/movk/movk quartet would be needed to
materialise the address.

My original goal was to merge the ARM version and this into a
target-agnostic pass in lib/Target (or somewhere else appropriate).
But getting rid of the whole mess from AArch64 *is* tempting. It took
me at least two attempts to get it right, and that was copying what
was already there.

I think I'll see if I can get anything resembling sane and
non-artificial benchmark numbers.

Tim.



More information about the llvm-commits mailing list