[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

Mon Apr 27 08:01:45 PDT 2020

sfertile added a comment.

In D78431#2000967 <https://reviews.llvm.org/D78431#2000967>, @agl wrote:

> Sorry about delocate. It is profoundly weird, motivated purely by compliance with FIPS regulations, and we don't want it to cause any problems.

No need to apologize, the linked documentation does a good job explaining why delocate does what it does, and the tests make it really easy to see what the transformations for Power are in practice. When I saw that the tests have input assembly that take the address of a toc-entry it got me thinking about if the gcc section-anchor option could produce code from source that takes the address of a toc-entry.

> The POWER ABI is also non-trivial and it's possible that we're doing invalid things that have only worked because of luck.

All the transformations I looked at were ABI compliant, and I don't think there is anything in the ABI disallowing taking the address of a toc-entry. Both BFD and Gold disable toc-optimizations for these instructions so I would say that is pretty solid evidence showing it is a supported construct.

FWIW, I think I am OK with us landing a patch like this that will selectively unbreak the code that delocate emits. I'm going to poke around a bit more today though to see how hard a more general solution might be before approving this patch.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78431