[PATCH] D147544: [BOLT] Move from RuntimeDyld to JITLink

Mon Apr 10 03:37:47 PDT 2023

Amir added a comment.

In D147544#4254306 <https://reviews.llvm.org/D147544#4254306>, @lhames wrote:

> In D147544#4247007 <https://reviews.llvm.org/D147544#4247007>, @rafauler wrote:
>
>>> Is BOLT taking a relocatable file as input, or an executable / dylib?
>>
>> BOLT's input is a final executable / .so file.
>>
>> Here's how BOLT operates at a high level.
>>
>> 1. Run a disassembler to create MCInst objects for each instruction in a function it wants to patch.  (it does more than that, such as creating cfgs, but I'll skip for the purposes of this discussion)
>> 2. After MCInsts get shuffled around to take advantage of a better code layout, we wend it to the assembler (via the MCStreamer interface).
>> 3. Assembler resolves internal fixups, generates regular ELF relocations for symbols that are not local (for example, references to other functions or global data in that binary).
>> 4. We feed that to RuntimeDyld to patch these relocations for us. RuntimeDyld actually has no idea where are these global symbols, so it asks us "where is foobar", we know where it is because we read the full symbol table of that binary (and using other techniques as well), so we answer RuntimeDyld back with all of the addresses it needs to resolve.
>> 5. Relocations are processed and the code is available in a blob of memory.
>> 6. We copy that blob of memory back to the final binary, at the location we want to patch.
>
> Is this operating per-function and patching the relocated code for that function back into the original binary then? I had assumed that you were creating a whole new ELF container.

BOLT operates per-function, the optimized function is placed in a newly-created .text section (or is split between .text and .text.cold), or, if the function is not updated, it's copied to .bolt.org.text and only the external references are patched.

Creating a new ELF container is something that BOLT wants to avoid – because in that case BOLT would need to understand and update all relocations, including data-to-data relocations, which is outside of our scope. There's an ongoing effort to support this mode to reduce the final binary size but it's still a WIP (D144560 <https://reviews.llvm.org/D144560>).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147544