[llvm-commits] [patch][gold plugin] Don't internalize symbols in objects that we will use as pass-through

[Rafael Espindola]

Sorry for taking so long to reply. Will try to address all the comments here.

> ... or ... The LLVM optimizer do not optimize away the symbols whose
> reference may be introduced by LLVM codegen (how to arrange this can
> be considered LLVM internal detail). The traditional linker can dead
> strip such symbols later on if their reference is not introduced by
> LLVM codegen phase.

This is probably the correct solution. In a way, it is a finer grained
version of what I did. It does per symbol what I did per library. My
only concern with it is: how easy would this be to maintain? We would
need to keep the list of symbols in some central (per arch) location
and make that information available to libLTO. We also have to make
sure the backend doesn't introduces calls to functions not in that
list.

About having to split the files to have one function per file. That is
a good thing, but while I didn't hit an issue with it, I did noticed
some object files with more than one symbol per file.

The issue I noticed is gold is in more details:
*) In the first pass over the archive members, the members that
provide a definition to currently undefined reference are loaded
correctly.
*) Members that provide symbols that match a placeholder are cached as
not being needed and skipped in the in the following iterations, even
if they would provide a definition for a now undefined symbol

This creates a somewhat funny error case: The link fails if the plugin
passes libc once, but works if it passes it multiple times.

While it is possible to fix this by checking if the symbol is a
placeholder, I don't think that is the correct fix. If possible we
should try to implement something that avoids having multiple copies
of a function.

As for the usefulness of having libc (and in the native client case,
its dependencies) as bitcode, the answer is that I don't know. I am in
a chicken and egg problem as I was hitting this link time errors. Even
with this fixed it will take some time before I can have useful
benchmarks. Ah, and not internalizing in LLVM means that it cannot
make the symbol private. The function can still be inlined for example
(but a copy is kept).

Devang, Nick, how hard do you guys think it would be to implement the
proposal of not internalizing functions the codegen can produce calls
to? If not too hard, I think I can keep this patch (locally if needed)
as a short term solution while I implement it on the side.

> -
> Devang
>

Thanks a lot,
-- 
Rafael Ávila de Espíndola