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

Peter Smith via llvm-dev
2018-05-21T14:34:11Z

Hello Eric,

If you do decide to investigate the linker script route, the ALIGN
builitin function might be useful. I think the simplest way is to do
something like:
.text ALIGN(0x1000) : { *(.text) }
.my_next_section ALIGN (0x1000) : { *(my_next_section) }
Bothe .text and .my_next_section would start at 4k boundaries.

Link to docs:
https://sourceware.org/binutils/docs/ld/Builtin-Functions.html#Builtin-Functions

Peter

On 21 May 2018 at 14:23, Eric Gorr via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> Thank you for providing the explanation for how ADRP works...something I
> should have done myself.
>
> With this explanation in hand, one other alternative I was looking at was
> using a linkerscript to essentially rebase the code and have ADRP
> instructions that would address the correct location as a result. However,
I
> am not a linkerscript expert, so I am not sure if such a thing is even
> possible or would make much sense. However, it may provide a legitimate
> shortcut to a solution which doesn't involve adding a feature to the
> toolchain.
>
>
> On Mon, May 21, 2018 at 9: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.
>>
>> 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.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>