[PATCH] D36576: Fix -fPIC handling on arm64

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

As well as strings it seems like absolute references are also used for global variables that are DSO local. Always going via the GOT is one possible solution, however I don't think it is necessarily the best solution as there are PC relative versions of the MOVW relocations such as R_AARCH64_MOVW_PREL_G0. These could be used to load the offset to the DSO local rather than going via the GOT. Unfortunately these relocations don't seem to be implemented yet in AArch64 so it looks like going via the GOT is better than producing a non-PIC sequence.

However while looking at the relative cost of using a PC-relative sequence of MOV/MOVK versus going via the .got I noticed that even for -mcmodel=large we are using the sequence:

  	adrp	x8, :got:glob
  	ldr	x8, [x8, :got_lo12:glob]
  	ldr		w0, [x8]

If your definition of -mcmodel=large is "no limit on segment size" then this sequence doesn't qualify as the adrp has a limit of 4Gb. As I understand it we would have to use PC-relative MOV, MOVK or a load from a literal pool to access the GOT rather than use ADRP.

If we permit the use of ADRP in -mcmodel=large to access the GOT then when using PIC why not use the small code sequence way to access DSO locals with:

  	adrp	x0, .L.str
  	add	x0, x0, :lo12:.L.str
  	ret



================
Comment at: lib/Target/AArch64/AArch64Subtarget.cpp:128
                                           const TargetMachine &TM) const {
+  // Large model would otherwise result in text relocations
+  if (TM.getCodeModel() == CodeModel::Large
----------------
To me the comment implies that we are masking the problem that an absolute code-sequence is chosen for PIC by choosing an alternative code sequence, I think we need a bit more detail about why we are making the choice.


Repository:
  rL LLVM

https://reviews.llvm.org/D36576