Should we use R_ARM_MOVT_PREL for ARM PIC?

[Peter Smith via llvm-commits]

Hello Rafael,

I don't have a particular good answer for why there is a difference in
code-generation right now.

With respect to the relocations, I think there might already be
movw/movt relocations that can do some of what you want.
The base relative versions of the relocations are:
R_ARM_MOVT_BREL
R_ARM_MOVW_BREL
R_ARM_MOVW_BREL_NC
R_ARM_THM_MOVT_BREL
R_ARM_THM_MOVW_BREL
R_ARM_THM_MOVW_BREL_NC

These are all of the form ((S + A) | T) – B(S)

where B(S) is defined as:

B(S) is the addressing origin of the output segment defining the
symbol S. The origin is not required to be the base address of the
segment. This value must always be word-aligned.

The wording of B(S) is vague enough for platforms such as Linux to say
what the addressing origin of B(S). It could be defined in terms of
the GOT.

If you've got something different in mind and want to make a proposal
for a new relocation type the ABI documents have an email address on
the front of the document that can be used.

Link to ARM ELF for convenience:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf

Peter

On 20 June 2016 at 21:09, Renato Golin <renato.golin at linaro.org> wrote:
> Adding Peter & Adhemerval.
>
> cheers,
> --renato
>
> On 20 June 2016 at 19:54, Rafael Espíndola <llvm-commits at lists.llvm.org> wrote:
>> While refactoring some code I noticed that
>>
>> @a = hidden global i32 42
>> define i32* @f()  {
>>   ret i32* @a
>> }
>>
>> produces
>>
>>         movw    r0, :lower16:(_a-(LPC0_0+8))
>>         movt    r0, :upper16:(_a-(LPC0_0+8))
>> LPC0_0:
>>         add     r0, pc, r0
>>
>> When targeting MachO but
>>
>>
>>         ldr     r0, .LCPI0_0
>> .LPC0_0:
>>         add     r0, pc, r0
>> ...
>>
>> .LCPI0_0:
>>         .long   a-(.LPC0_0+8)
>>
>> When targeting ELF.
>>
>> We could use R_ARM_MOVT_PREL on ELF to use a movw/movt pair and an add
>> instead of a load and an add. Would that be an improvement? We use
>> movw/movt for non PIC code, so I assume so.  Should I open a bug?
>>
>> On a similar note, why there is no movw/movt pc relative relocation
>> that points to a got entry? That would be handy for when the variable
>> can be preempted.
>>
>> Cheers,
>> Rafael
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits