Eric Gorr via llvm-dev
2018-May-21 12:31 UTC
[llvm-dev] 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>
Bruce Hoult via llvm-dev
2018-May-21 12:57 UTC
[llvm-dev] ARM64, dropping ADRP instructions, and ld.lld
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 20bit 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>
Tim Northover via llvm-dev
2018-May-21 12:57 UTC
[llvm-dev] ARM64, dropping ADRP instructions, and ld.lld
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.
Tim Northover via llvm-dev
2018-May-21 13:04 UTC
[llvm-dev] ARM64, dropping ADRP instructions, and ld.lld
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.
Eric Gorr via llvm-dev
2018-May-21 13:14 UTC
[llvm-dev] ARM64, dropping ADRP instructions, and ld.lld
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>