[PATCH] D58378: [PowerPC]Leverage the addend in the TOC relocation to do the address calculation

[qshanz via Phabricator via llvm-commits]

steven.zhang added a comment.

In D58378#1801609 <https://reviews.llvm.org/D58378#1801609>, @MaskRay wrote:

> In D58378#1801102 <https://reviews.llvm.org/D58378#1801102>, @steven.zhang wrote:
>
> > I get the reason about 0x8000 now.
> >
> >   #ha(value) Denotes the high adjusted value: bits 16 - 63 of the indicated value, compensating
> >   for #lo() being treated as a signed number. That is:
> >   #ha(x) = (x + 0x8000) >> 16
> >
>
>
> Yes.
>
> >   The TOC region commonly includes data items within the .got, .toc, .sdata, and .sbss sections. In the medium
> >   code model, they can be addressed with 32-bit signed offsets from the TOC pointer register. The TOC pointer
> >   register typically points to the beginning of the .got section + 0x8000, which permits a 2 GB TOC with the
> >   medium and large code models.
>
> `-0x80008000 <= address - .TOC. + r_addend < 0x7fff8000`
>
> If address - .TOC. can be as large as 0x7fff8000 (this may happen with huge .data or .bss), then you cannot leverage any positive value of r_addend.. Though, I believe this situation may be rare. You may try a smaller cut-off value, say, 0x100, and see if it is beneficial. Be aware that if the code references multiple elements of a global array, e.g. a[0] a[1] a[2] ... a[99], don't just create 100 TOC entries.


Regarding to the references of array elements, it is another issue I think. We should use one TOC entry to point to the base address, and load it with offset. LLVM PowerPC backend didn't work this way w/o this patch.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58378/new/

https://reviews.llvm.org/D58378