llvm dev - May 2018 - ARM64, dropping ADRP instructions, and ld.lld

Hello,

I am working in an embedded environment with somewhat restrictive memory
requirements where the page alignment requirements of an ADRP instruction
cannot be guaranteed.

With the ld program inside of the Xcode, there is a -preload flag which
causes ADRP instructions to be dropped, and generates code that is 100%
position independent.

As near as I can determine, ld.lld does not have this same feature. I am
wondering if I am missing something, if such a feature is being planned, or
if there is an alternative I have not considered yet.

Regards,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180521/f69a5069/attachment.html>

Are you sure about that?

In the documentation for the ADRL pseudo it says:

"ADRL assembles to two instructions, an ADRP followed by ADD."

"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).

In all cases, if you then do an add immediate with a 12 bit signed literal
(16 bit for MIPS) then you've got a relative offset from the current PC<
accurate to the byte, anywhere in a +/- 2 GB range.

The actual alignment of the PC is irrelevant. It's not like the ADRP or
AUIPC sets the low 12 bits to zero or something. It leaves them alone (as
it finds them in the PC).

On Tue, May 22, 2018 at 12:31 AM, Eric Gorr via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello,
>
> I am working in an embedded environment with somewhat restrictive memory
> requirements where the page alignment requirements of an ADRP instruction
> cannot be guaranteed.
>
> With the ld program inside of the Xcode, there is a -preload flag which
> causes ADRP instructions to be dropped, and generates code that is 100%
> position independent.
>
> As near as I can determine, ld.lld does not have this same feature. I am
> wondering if I am missing something, if such a feature is being planned, or
> if there is an alternative I have not considered yet.
>
> Regards,
> Eric
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180522/f93f80d3/attachment.html>

Hi Eric,

On 21 May 2018 at 13:31, Eric Gorr via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> I am working in an embedded environment with somewhat restrictive memory
> requirements where the page alignment requirements of an ADRP instruction
> cannot be guaranteed.
It sounds like you're relying on the linker optimization hints that
Clang emits. As you've seen they're designed to allow the linker to
convert adrp/add pairs into simpler nop/ldr sequences. If it works for
your purposes, great; but bear in mind it was designed as a
microarchitectural optimization so it's not guaranteed to trigger or
be able to remove all adrps if it does.
> As near as I can determine, ld.lld does not have this same feature. I am
> wondering if I am missing something, if such a feature is being planned,
MachO support in lld is pretty immature compared to ELF and it
certainly doesn't look like it's supported yet. I'm afraid I'm
not
sure about the longer-term plans.
> or if there is an alternative I have not considered yet.
Ideally this would probably be handled by implementing proper
-mcmodel=tiny support in LLVM so that only ADR instructions are
emitted in the first place (instead of leaving you with a bunch of
NOPs). In ELF-land that probably wouldn't be too hard (there are
already relocations for it in the spec), but MachO is chronically
starved of free locations so that might get very nasty very quickly.

Cheers.

Tim.

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.

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.

Cheers.

Tim.

I don't care about Mach-O at all. ELF is sufficient.

I can certainly submit a bug report at https://bugs.llvm.org requesting a
-mcmodel=tiny feature which would cause ADR instructions to be emitted in
the first place.

This is of great enough interest to me that I may be able to contribute
some time to make it happen, but not generally working this deep in the
toolchain, it would likely need to be more along the lines of assisting
someone who knew what they were doing and could provide guidance rather
then me taking on the whole task myself.

As an educated opinion, how difficult might something like this be?
minutes? hours? days? weeks? months?




On Mon, May 21, 2018 at 8:57 AM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> Hi Eric,
>
> On 21 May 2018 at 13:31, Eric Gorr via llvm-dev <llvm-dev at
lists.llvm.org>
> wrote:
> > I am working in an embedded environment with somewhat restrictive
memory
> > requirements where the page alignment requirements of an ADRP
instruction
> > cannot be guaranteed.
>
> It sounds like you're relying on the linker optimization hints that
> Clang emits. As you've seen they're designed to allow the linker to
> convert adrp/add pairs into simpler nop/ldr sequences. If it works for
> your purposes, great; but bear in mind it was designed as a
> microarchitectural optimization so it's not guaranteed to trigger or
> be able to remove all adrps if it does.
>
> > As near as I can determine, ld.lld does not have this same feature. I
am
> > wondering if I am missing something, if such a feature is being
planned,
>
> MachO support in lld is pretty immature compared to ELF and it
> certainly doesn't look like it's supported yet. I'm afraid
I'm not
> sure about the longer-term plans.
>
> > or if there is an alternative I have not considered yet.
>
> Ideally this would probably be handled by implementing proper
> -mcmodel=tiny support in LLVM so that only ADR instructions are
> emitted in the first place (instead of leaving you with a bunch of
> NOPs). In ELF-land that probably wouldn't be too hard (there are
> already relocations for it in the spec), but MachO is chronically
> starved of free locations so that might get very nasty very quickly.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180521/26334ab3/attachment.html>