[llvm] r185882 - Don't run internalize if we're outputing bit-code and not an object file.

[Reid Kleckner]

On Mon, Jul 8, 2013 at 8:10 PM, Bill Wendling <isanbard at gmail.com> wrote:

> On Jul 8, 2013, at 4:54 PM, Chris Lattner <clattner at apple.com> wrote:
>
> > On Jul 8, 2013, at 4:23 PM, Bill Wendling <isanbard at gmail.com> wrote:
> >
> >> Author: void
> >> Date: Mon Jul  8 18:23:03 2013
> >> New Revision: 185882
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=185882&view=rev
> >> Log:
> >> Don't run internalize if we're outputing bit-code and not an object
> file.
> >>
> >> The problem with running internalize before we're ready to output an
> object file
> >> is that it may change a 'weak' symbol into an internal one, but that
> symbol
> >> could be needed by an external object file --- e.g. with arclite.
> >
> > I don't understand: how does output format affect symbol visibility?
> >
> If it changes a symbol from 'weak' to 'non-weak', then that symbol may be
> optimized away if the compiler thinks that it's no longer used. But if it's
> running 'ld -r', it doesn't know if the symbol can be optimized away
> because it doesn't have all of the source code available for it. Given
> this, it doesn't really make sense to run internalize before outputting a
> .bc file. That code hasn't gone through code generation yet, so the linker
> doesn't really know which of its symbols can be changed from 'weak' to
> 'non-weak'.
>

ld -r seems really, really different from normal LTO.  Is there some other
flag to detect that?  Are there any other passes that LTO uses that assume
it has all the code in the final image?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130708/181ff207/attachment.html>