[PATCH] D51030: [AArch64] Optimise load(adr address) to ldr address

Peter Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 21 04:14:31 PDT 2018


peter.smith added a comment.

In https://reviews.llvm.org/D51030#1207255, @dmgreen wrote:

> Unfortunately I'm hitting a number of linker problems in testing this.
>
> - Armlink seems to do fine, but I am testing embedded code there.
> - ld.bfd links the test-suite fine with fpic (except for the expected errors where relocations are out of range). But without pic gives an error about relocating against stderr that I'm not sure of yet, but might point to this alignment check being wrong in some way. Unfortunately the errors are not clear what is out of range, it may be a legitimate error (although ld.gold and lld both are "successful" at linking the same program).


Some thoughts:

- When compiling PIC I'm guessing that the reference to stderr will go via the GOT, this is likely to be closer to the code than the data.
- I can't see anything obviously wrong with the BFD code for handling LO19
- LLD has a different section layout to BFD, in particular it puts the ro-data before code so it may be just luck that puts stderr in range for LLD. You may be able to reproduce by feeding LLD the ld.bfd linker map file.
- One way to find out whether the out of range error is correct is to use the small code model and see how big the distance between stderr and the equivalent place in the relocation is. Accounting for the tiny code model, does this look credible?

> - ld.gold doesn't like load literal relocations, producing invalid instructions.

I think it will be worth filing a binutils bug, a quick check of the entry for aarch64-reloc.def in gold shows us:

  ARD(LD_PREL_LO19		 , STATIC ,  AARCH64    ,   Y,  -1,   20,20		  ,    2,20 , Symbol::RELATIVE_REF , 			     LDST  )

with the LDST being the key part. I think that should be LD as there isn't a store literal and the LDST category of relocations have a different set of encoding rules.

> - lld, with some extra patches, does fine for anything that isn't a tls relocation I think.

If there is anything I can do to help here let me know?


https://reviews.llvm.org/D51030





More information about the llvm-commits mailing list