[llvm-dev] ARM64, dropping ADRP instructions, and ld.lld

[Bruce Hoult via llvm-dev]

On Tue, May 22, 2018 at 1:04 AM, Tim Northover <t.p.northover at gmail.com>
wrote:

> On 21 May 2018 at 13:57, Bruce Hoult via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > "ADRL produces position-independent code, because the address is
> calculated
> > relative to PC."
> >
> > From this, I'd expect ADRP to simply do Xd <- PC + n*4096, where n is a
> 20
> > bit number, just like AUIPC in RISC-V (also a 20 literal multiplied by
> 4096)
> > or AUIPC in MIPS (16 bits multiplied by 65636 there).
>
> Afraid not. It really is (PC & ~0xfff) + n * 0x1000. So it does
> require 12-bit alignment of any code section.
>

Wow! My mistake. Knock me down with a leaf.


> Now that you mention the MIPS & RISC-V alternatives, I'm not sure why
> ARM actually made that choice. It obviously saves you a handful of
> transistors but I can't quite believe that's all there is to it.
>

I'm not quite sure how passing 12 bits through an ALU unchanged uses more
transistors than inserting muxes to pass them through for some instructions
and replace them with zeros for other instructions :-)

I find Aarch64 inexplicable. There are some truly brilliant touches such as
the bit patterns in immediate operands for logical instructions, or the
pass-through/invert/negate/increment in the conditional select instruction,
or the bitfield move that can extract/insert/sign extend/truncate. But
there are are some things that make me think the designers operated in a
complete vacuum, not aware of the brilliant bits in ARM32 or other prior
art. This is one of them. The abandonment of mixed 16/32 bit opcodes that
took Thumb2 to such dominance is another. MIPS have copied that several
times with the recently announced nanoMIPS looking pretty good (and with
16, 32 & 48 bit opcodes designed in). RISC-V was of course designed for
optional variable length 16&32 bit (and longer in future) opcodes from
almost the beginning. All of these give x86_64-beating code density without
the sequential decode nightmares.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180522/9ee74b63/attachment.html>