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

Hello Eric,

My understanding is that the ADRP instruction isn't supposed to be
used on its own. The result of the ADRP provides a 4k aligned address,
the following instruction such as an LDR has an immediate offset that
can reach any address within the 4k page. For example to get the
address of a global variable var with -fpic in ELF:
adrp x0, :got:var                   // relocation R_AARCH64_ADR_GOT_PAGE var
ldr x0, [x0, :got_lo12:var]     // relocation R_AARCH64_LD64_GOT_LO12_NC

The resulting code section is 4 byte aligned, I'm not sure where the
requirement for 4k aligned sections come from unless you are planning
to use ADRP alone? Do you need just one instruction for the purposes
of reducing code size? Another possibility if you don't care about
code-size but mustn't use ADRP is (range permitting) to have the
linker turn an ADRP to ADR and replace the following instruction with
a NOP. I think that is something you'd need to maintain downstream
though.

If you can use gcc then that supports -mcmodel=tiny. How long it would
take to implementing it in LLVM would depend on how familiar you are
with LLVM and how much you know of the specification of -mcmodel=tiny;
on the assumption you aren't that familiar I'd guess at an order of
weeks.

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
>

On 21 May 2018 at 14:52, Peter Smith <peter.smith at linaro.org>
wrote:
> The resulting code section is 4 byte aligned, I'm not sure where the
> requirement for 4k aligned sections come from unless you are planning
> to use ADRP alone?
I think it's the segments that need to be 4K aligned (i.e. after
linking). Normally this isn't really an extra constraint because
you're just going to map them in with the MMU anyway, but in strange
embedded situations I could see it being a problem.

Consider the fully linked sequence:

    adrp x0, #0
    add x0, x0, #8

Starting at 0x1000 this would result in x0 == 0x1008 == pc, at 0x1ffc
it would result in x0 == 0x1008 != pc. Not good for
position-independence (or static positioning, but for different
reasons not illustrated by that example).

Cheers.

Tim.

Ok, thanks for the clarification that makes sense.

Peter

On 21 May 2018 at 15:03, Tim Northover <t.p.northover at gmail.com>
wrote:
> On 21 May 2018 at 14:52, Peter Smith <peter.smith at linaro.org>
wrote:
>> The resulting code section is 4 byte aligned, I'm not sure where
the
>> requirement for 4k aligned sections come from unless you are planning
>> to use ADRP alone?
>
> I think it's the segments that need to be 4K aligned (i.e. after
> linking). Normally this isn't really an extra constraint because
> you're just going to map them in with the MMU anyway, but in strange
> embedded situations I could see it being a problem.
>
> Consider the fully linked sequence:
>
>     adrp x0, #0
>     add x0, x0, #8
>
> Starting at 0x1000 this would result in x0 == 0x1008 == pc, at 0x1ffc
> it would result in x0 == 0x1008 != pc. Not good for
> position-independence (or static positioning, but for different
> reasons not illustrated by that example).
>
> Cheers.
>
> Tim.