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

Job Noorman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 17 03:22:52 PDT 2023

jobnoorman added a comment.

In D147544#4270637 <https://reviews.llvm.org/D147544#4270637>, @rafauler wrote:

> If it is not the intent of JITLink to support such use cases, and given that BOLT has a unique use case on these components, one thing we can consider doing is to just copy RuntimeDyld to bolt's folder as a specific bolt-only private linker. In that way, BOLT doesn't get in the way of deprecating RuntimeDyld and doesn't put unwanted requirements on the JITLink API.

While this would solve the immediate `RuntimeDyld` issue, I feel this approach would be suboptimal since it puts the burden of maintaining the linker entirely on the shoulders of the BOLT devs. For example, RISC-V support in `RuntimeDyld` is incomplete and would need to be implemented in isolation as part of BOLT. Besides BOLT not benefiting from an externally maintained project, I believe the reverse is also true: using an external linker like `JITLink` will also benefit that project (e.g., a few minor fixes have been upstreamed while developing this patch).

Another example of this is support for linker relaxation; something that would probably be desirable to have on RISC-V in BOLT. Since this is rather subtle to implement correctly, it makes much more sense to me to do this as part of something like `JITLink` than privately in BOLT.

As for putting unwanted requirements on the `JITLink` API, I don't think this patch actually does that (please correct me if I'm wrong @lhames). I believe the way `LinkGraph`s are created and linked is entirely within the intended use of the API. The only thing that is "weird" is the way the result of linking is used (i.e., read back from memory instead of being executed). But I don't think this should put any unwanted requirements on `JITLink`.

  rG LLVM Github Monorepo



More information about the llvm-commits mailing list