This is an archive of the discontinued LLVM Phabricator instance.

AArch64: Unify relocation restrictions between MOVK/MOVN/MOVZ.
ClosedPublic

Authored by pcc on Jul 9 2019, 6:54 PM.

Details

Summary

There doesn't seem to be a practical reason for these instructions to have
different restrictions on the types of relocations that they may be used
with, notwithstanding the language in the ELF AArch64 spec that implies that
specific relocations are meant to be used with specific instructions.

For example, we currently forbid the first instruction in the following
sequence, despite it currently being used by clang to generate a global
reference under -mcmodel=large:

movz x0, #:abs_g0_nc:foo
movk x0, #:abs_g1_nc:foo
movk x0, #:abs_g2_nc:foo
movk x0, #:abs_g3:foo

Therefore, allow MOVK/MOVN/MOVZ to accept the union of the set of relocations
that they currently accept individually.

Diff Detail

Repository
rL LLVM

Event Timeline

pcc created this revision.Jul 9 2019, 6:54 PM

I think that this is reasonable given that the wording in the ABI was recently changed to relax some of the wording surrounding MOVZ and MOVK. In particular Table 4-7 and Table 4-8 where modified in version E, the latest version is F https://developer.arm.com/docs/ihi0056/latest/elf-for-the-arm-64-bit-architecture-aarch64-abi-2019q2-documentation

Unfortunately it looks like Table 4-11 and Table 4-12 still have the distinction between MOVZ and MOVK. I think that this is likely an oversight rather than a deliberate decision, but I'd like to check. I'm on holiday this week, so I'll need to wait till Monday to follow this up. I've added a couple of my colleagues who may be able to help in my absence.

I think that this is reasonable given that the wording in the ABI was recently changed to relax some of the wording surrounding MOVZ and MOVK. In particular Table 4-7 and Table 4-8 where modified in version E, the latest version is F https://developer.arm.com/docs/ihi0056/latest/elf-for-the-arm-64-bit-architecture-aarch64-abi-2019q2-documentation

Unfortunately it looks like Table 4-11 and Table 4-12 still have the distinction between MOVZ and MOVK. I think that this is likely an oversight rather than a deliberate decision, but I'd like to check. I'm on holiday this week, so I'll need to wait till Monday to follow this up. I've added a couple of my colleagues who may be able to help in my absence.

I've submitted a query to the ABI mailing list to see if anyone has a particular reason for not doing this for the pc and got relative versions. If no-one comes back with any good reason within a couple of days I'll approve.

peter.smith accepted this revision.Jul 18 2019, 2:33 AM

LGTM. I think that the change is worth making as no linker strictly interprets the ABI and checks the instruction encoding, and the calculation is good for all variants. I'm hoping to get the ABI wording relaxed in the next version.

This revision is now accepted and ready to land.Jul 18 2019, 2:33 AM
This revision was automatically updated to reflect the committed changes.