[PATCH] LTO: add API to set strategy for -internalize

[Duncan P. N. Exon Smith]

On Jan 10, 2014, at 4:31 PM, Nick Kledzik <kledzik at apple.com> wrote:

> Duncan and I had a long discussion about this.  This style of API addition
> is good from the linker’s perspective, because old linker’s still work and
> new linker’s can run with old libLTO by not calling this new API.
> 
> We do need three states, but the middle one needs to be changed to:
> 
> LTO_INTERNALIZE_FULL      the default (and the old behaviour).
> LTO_INTERNALIZE_HIDDEN    only internalize hidden symbols.
> LTO_INTERNALIZE_NONE      skip -internalize entirely.
> 
> One of the key insights in our discussion is that the Internalize pass does
> not make sense to run when doing “ld -r” to merge object files.  Internalize
> assumes you are about to do code-gen and see all symbols involved.
> With ld -r you are not about to do code-gen and the symbols that will exist
> in the final link are unknowable.  
> 
> So, in -r mode, the linker will use this new API to stop internalize pass.  
> But, ld -r has a twist.  By default ld -r wants visibility=hidden symbols to be 
> internalized, unless -keep_private_externs is used. Thus, the linker will do:
> 
>     ld -r                                         => LTO_INTERNALIZE_HIDDEN
>     ld -r  -keep_private_externs   => LTO_INTERNALIZE_NONE
> 
> -Nick 

Nick:  the new patch (attached below) is updated as per our conversation.  Thanks for the review!

Can anyone review the LLVM side?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lto-internalize-strategies-2.patch
Type: application/octet-stream
Size: 20134 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140110/ec9c3362/attachment.obj>
-------------- next part --------------