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

[Rafael Espíndola]

>> Even it we are now stuck with it in the C api, I would probably
>> implement it as close to the C api as possible. For example, please
>> don't keep the OnlyHidden option in createInternalizePass.
>
> Why?  It seems clean to me as is.  Rather than passing an enumerator where some values are invalid (but will never be passed), it's reduced to a Boolean flag.  Or do you think we should call createInternalizePass() even
> when LTO_INTERNALIZE_NONE?  Or what exactly?
>
> Sorry if I'm missing something obvious.

It is a simpler interface. For example, it is not immediately obvious
if given a OnlyHidden it should internalize all hidden or only the
subset passed on the list that is hidden. The big advantage of the lto
plugin interface is that all the logic for what symbols are needed by
the linker are in one place, the linker itself. There is still logic
in LLVM for symbols that llvm itself might need (like memcpy for
example).

Another more general issue is that this is ld64 specific. Given how
gold works (and how I hope to get lld working), it is trivial for the
linker to pass all the necessary information down and we should use
that. The situation in llvm is a bit convoluted right now with the
gold plugin implemented on top of the C lto api. My longer term plan
is to reorganize this as

* lib/LTO: Things that *any* linker doing LTO with llvm needs to know.
Things like don't internalize memcpy because CodeGen might add a
reference to it go in here. Not a stable API and defined in C++. When
we get to lld, it can use this directly.
* toos/gold: Implemented with lib/LTO. Handles any gold specific logic.
* tools/lto: Goes back to being just the ld64 api.

In such a division, if you and nick think that ld64 would benefit from
a particular api, it should be really uncontentious to add it to
tools/lto if it can be implemented in there. This is a case of such an
API. It can be implemented entirely in the linker (i.e., no extra API)
or in tools/lto without requiring modifications to the rest of LLVM.

Cheers,
Rafael