This is an archive of the discontinued LLVM Phabricator instance.

[LLVM-C][OCaml] Add a fast linker binding
Needs ReviewPublic

Authored by kren1 on Jul 22 2019, 3:01 AM.

Details

Summary

The current LLVM-C/Ocaml linker API is very slow when linking many files
together. This patch exposes and additional API that does not destroy
the Linker object between each linking call.

Diff Detail

Event Timeline

kren1 created this revision.Jul 22 2019, 3:01 AM
Herald added a project: Restricted Project. · View Herald Transcript
This revision is now accepted and ready to land.Jul 23 2019, 4:22 AM

@modocache could you commit this for me?

CodaFi requested changes to this revision.Jul 23 2019, 9:07 AM
CodaFi added a subscriber: CodaFi.
CodaFi added inline comments.
include/llvm-c/Linker.h
54

Can you document the lifetime of the linked module?

lib/Linker/LinkModules.cpp
617

Can you expose these two defaulted arguments in the bindings as well?

This revision now requires changes to proceed.Jul 23 2019, 9:07 AM
kren1 updated this revision to Diff 211440.Jul 24 2019, 1:32 AM
kren1 marked an inline comment as done.

Document lifetime of source, remove unnecessary arguments

kren1 marked an inline comment as done.Jul 24 2019, 1:35 AM
kren1 added inline comments.
lib/Linker/LinkModules.cpp
617

Exposing them is not trivial, because I would have to introduce new types for Flag and a trampoline for the callback. I removed them to be implicit and in line with LLVMLinkModules2. If you really want me to add them, I would prefer to do it as a separate diff.

CodaFi added inline comments.Jul 24 2019, 7:29 AM
lib/Linker/LinkModules.cpp
617

I realize it’s non-trivial, but our commitment to ABI compatibility makes revising these public interfaces much more difficult after the fact than getting it right up front.

FWIW, the result of the internalize bindings patch you have apply here as well, and you need only provide a thunk to translate the C binding flags to the few linker flags LLVM currently supports. If you’d like, I can generate that binding and tag you in a review, then you can rebase the OCaml bindings on top.

kren1 updated this revision to Diff 211547.Jul 24 2019, 10:18 AM

Properly expose the 2 default arguments to linkInModule

kren1 updated this revision to Diff 211685.Jul 25 2019, 1:17 AM
kren1 marked 2 inline comments as done.

Simplify memory management for the callback value

CodaFi added inline comments.Jul 26 2019, 6:45 PM
include/llvm-c/Linker.h
35

These names should be qualified as above.

typedef enum {

LLVMLinkerFlagsNone = 0,
LLVMLinkerFlagsOverrideFromSrc = 1,
LLVMLinkerFlagsLinkOnlyNeeded = 2

} LLVMLinkerFlags;

kren1 updated this revision to Diff 212049.Jul 27 2019, 2:57 AM
kren1 marked an inline comment as done.

Qualify linker flags

whitequark requested changes to this revision.Jul 27 2019, 3:03 AM
whitequark added inline comments.
bindings/ocaml/linker/linker_ocaml.c
40

I think the proliferation of non-reentrant/non-threadsafe functions in the API is an issue. (Right now OCaml has a global lock, but a multicore runtime is in works.) The approach in D65138 is better, but still seems error-prone to me; I'll need to take a closer look at the OCaml runtime feature to see if perhaps a better one is possible.

This revision now requires changes to proceed.Jul 27 2019, 3:03 AM
kren1 marked an inline comment as done.Jul 27 2019, 5:30 AM
kren1 added inline comments.
bindings/ocaml/linker/linker_ocaml.c
40

I can't do the D65138 approach, because the callback doesn't pass a context, but it would be easier in this case because there is no need to worry about life times.

whitequark added inline comments.Jul 27 2019, 5:35 AM
bindings/ocaml/linker/linker_ocaml.c
40

I would personally consider any C API function that does not take a context a (usability) bug, since the LLVM C API is primarily useful for writing bindings from other languages, most of which have some kind of closure mechanism. I think in this case it is clearly justifiable to add an LLVMLinkInModule2 that fixes this.

kren1 marked an inline comment as done.Jul 27 2019, 5:44 AM
kren1 added inline comments.
bindings/ocaml/linker/linker_ocaml.c
40

Ah good point, I'Il do that. Thanks

kren1 updated this revision to Diff 212136.Jul 29 2019, 2:36 AM
kren1 marked 2 inline comments as done.

Pass the closure via context instead of global variable

kren1 added a comment.Aug 22 2019, 1:30 AM

Any news regarding this patch?

I won't be able to review this (or other patches) until at least mid-September.

Can we get review on this patch.

@CodaFi Could you please comment on the current state of the patch?

kren1 added a comment.Nov 27 2019, 6:11 AM

Any news on this?

@kren1 Do you have any objections to my suggestion of adding LLVMLinkInModule2? I think that's the only remaining issue to address.

@whitequark I think I decided to fold the functionality of LLVMLinkInModule2 into the LLVMLinkInModule. Since I'm adding the function in the first place, I thought there is no need to have the C function without those additional parameters.

Or did I misunderstand what you meant by adding the LLVMLinkInModule2?

whitequark resigned from this revision.Mar 10 2020, 2:42 PM
hiraditya resigned from this revision.Jul 3 2020, 2:57 PM