Page MenuHomePhabricator

[LTO][Legacy] Add new C inferface to query libcall functions
ClosedPublic

Authored by steven_wu on Sep 13 2019, 12:29 PM.

Details

Summary

This is needed to implemented the same approach as lld (implemented in r338434)
for how to handling symbols that can be generated by LTO code generator
but not present in the symbol table for linker that uses legacy C APIs.

libLTO is in charge of providing the list of symbols. Linker is in
charge of implementing the eager loading from static libraries using
the list of symbols.

rdar://problem/52853974

Diff Detail

Repository
rL LLVM

Event Timeline

steven_wu created this revision.Sep 13 2019, 12:29 PM
Herald added a project: Restricted Project. · View Herald Transcript

How are these interfaces usually tested?

llvm/include/llvm-c/lto.h
798 ↗(On Diff #220152)

s/visile/visible

lto.cpp is not really tested. Maybe we can test this by move this into lib/LTO then integrate the new version into lld?

How many symbols are there today? Do we want this overhead of a function call for each? Could you instead return a count and array pointer (like argc and argv) or have a "foreach" function that takes a block and calls it back for each symbol?

How many symbols are there today? Do we want this overhead of a function call for each? Could you instead return a count and array pointer (like argc and argv) or have a "foreach" function that takes a block and calls it back for each symbol?

I am just following the old convention. The number of symbols are around 500. foreach is not that cheaper because it is one function call per iteration. I am fine with either solution.

How many symbols are there today? Do we want this overhead of a function call for each? Could you instead return a count and array pointer (like argc and argv) or have a "foreach" function that takes a block and calls it back for each symbol?

I am just following the old convention. The number of symbols are around 500. foreach is not that cheaper because it is one function call per iteration. I am fine with either solution.

Adding an argv equivalent seems reasonable to me:

unsigned int lto_get_num_runtime_lib_symbols(void);
const char **lto_get_runtime_lib_symbol_names(void);

That locks down the implementation as an array of const char * but that's probably fine.

llvm/include/llvm-c/lto.h
804 ↗(On Diff #220152)

This is C, so you need (void) here to have a prototype.

  • [LTO][Legacy] Add new C inferface to query libcall functions
  • [lld] Update lld to use the new LTO API to add libcall symbols
This revision is now accepted and ready to land.Sep 16 2019, 10:15 AM
This revision was automatically updated to reflect the committed changes.

I break this into two commits. r372021 and r372022.