[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 12:26:38 PDT 2020

sfertile added a comment.

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?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78431