[PATCH] D146546: [BOLT][RFC] Implement composed relocations

Wed Mar 22 03:26:50 PDT 2023

jobnoorman added a comment.

In D146546#4212407 <https://reviews.llvm.org/D146546#4212407>, @treapster wrote:

>> The implemented feature isn't used (afaict) by X86 or AArch64 so this should in principle be NFC
>
> In fact we need to have it for other targets because for example some golang <https://reviews.llvm.org/D124347> structures contain offsets into .text which is ok if we know output .text address, but if we land https://reviews.llvm.org/D144560 it would be cumbersume to reserve .text address ahead of time, and i think other cases of symbol diffs or other expressions may emerge outside of golang. Last week i tried to merge golang with -rewrite and ended up creating bogus relocation type which can contain arbitrary symbol expression and has advantages of not using multiset and extra indirection at the cost of Relocation's PODness and privatizing Relocation::Symbol. However, in case of RISCV we'll need to collect composed relocations in a single expression while reading them and only then add them to BinarySection. Here's the patch, should i open a competing RFC with it?:)F26864023: 0001-BOLT-Use-raw-MCExpr-to-express-symbol-differences.patch <https://reviews.llvm.org/F26864023>

Thanks, this is an interesting alternative approach! I believe it could indeed be used to implement composed relocations on RISC-V, at least for the ones I currently care about.

I do think there is some information loss, though: since the relocation type is replaced by a "bogus" one, we won't know what the original type was. For composed relocations, the type of the last one determines how the value is written. Since we lost that type, this could be an issue. Now, for the relocations on RISC-V that are used in a composed way (ADD32/SUB32), this doesn't matter since their size corresponds to the "bogus" ones so this might just be a mere theoretical issue.

In any case, since this heavily changes one of the core data structures in BOLT, I'll leave it for others to decide which approach is preferable :)

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146546