[PATCH] D78431: [ELF][PPC64] Don't perform toc-indirect to toc-relative relaxation for R_PPC64_TOC16_HA not followed by R_PPC64_TOC16_LO_DS

Tue Apr 21 13:33:33 PDT 2020

MaskRay added a comment.

In D78431#1995205 <https://reviews.llvm.org/D78431#1995205>, @sfertile wrote:

> Interesting. I wasn't aware that taking the address of a toc entry was allowed when I implemented the toc-optimizations 😦 . I'm not sure we can peek at just the next relocation though to see if we can optimize or not. For example consider:
>
>     addis 4, 2, .LC1 at toc@ha  # R_PPC64_TOC16_HA, should be optimized.
>     addis 3, 2, .LC0 at toc@ha  # R_PPC64_TOC16_HA, should *NOT* be optimized.
>     ld    4,    .LC1 at toc@l(4)  # R_PPC64_TOC16_LO_DS, should be optimzied
>     addi  3, 3, .LC0 at toc@l   # R_PPC64_TOC16_LO, should *NOT* be optimized.
>     blr
>  
>   AES_encrypt:
>     .long 0xabcd1234
>  
>     .data
>   Sym: 
>     .long 0
>  
>   .LC0:
>     .tc AES_encrypt[TC], AES_encrypt
>   .LC1:
>     .tc Sym[TC], Sym
>
>
> My initial though are we will have to scan all the .toc relocs upfront to determine which are optimizable, but I need to spend a bit more time thinking about this to make sure I fully understand the problem.
>
> I don't really know GO, but what in the language ends up producing assembly that takes the address of the toc entry for a symbol?

boringssl delocate (there is some documentation on https://github.com/google/boringssl/blob/master/crypto/fipsmodule/FIPS.md ; my understanding is very limited, too) is the only tool that takes the address of a TOC entry. I believe all of our internal ppc targets can be built if we use `--no-toc-optimize`. After this bug fixed, there may be another bug related to delocate generated assembly, but no other tool generates such strange HA/LO pairs.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78431