[llvm] r199244 - Reapply "LTO: add API to set strategy for -internalize"

Duncan P. N. Exon Smith dexonsmith at apple.com
Wed Apr 2 11:14:09 PDT 2014


On Apr 2, 2014, at 7:16, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:

> Sorry I missed this the first time.

In case you haven't found it, here's the review [1].

[1]: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140106/201055.html

> If I understand it correctly, it
> exist so that we don't internalize symbols when using ld -r.

Right.

  - INTERNALIZE_HIDDEN is used by ld -r
  - INTERNALIZE_NONE is used by ld -r -keep_private_externs

I expect INTERNALIZE_NONE is generally useful for creating shared objects, where
nothing should be internalized.  I'm not sure if there are other use cases for
INTERNALIZE_HIDDEN.

> Why can't
> the linker simply list the symbols that should not be internalized in
> that case as it does for every other file?

For INTERNALIZE_NONE, that requires listing every symbol in the bitcode.  For
INTERNALIZE_HIDDEN, it would be on the same scale (listing every symbol that
isn't hidden).  The LTO side would then be dealing with extremely large sets of
symbols to export.

Adding API was more efficient and easier to reason about.

Is it causing a problem, or are you generally concerned about C API bloat?



More information about the llvm-commits mailing list