[llvm] r193718 - Produce .weak_def_can_be_hidden for some linkonce_odr values

[John McCall]

On Oct 30, 2013, at 3:08 PM, Rafael Espindola <rafael.espindola at gmail.com> wrote:
> Author: rafael
> Date: Wed Oct 30 17:08:11 2013
> New Revision: 193718
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=193718&view=rev
> Log:
> Produce .weak_def_can_be_hidden for some linkonce_odr values
> 
> With this patch llvm produces a weak_def_can_be_hidden for linkonce_odr
> if they are also unnamed_addr or don't have their address taken.
> 
> There is not a lot of documentation about .weak_def_can_be_hidden, but
> from the old discussion about linkonce_odr_auto_hide and the name of
> the directive this looks correct: these symbols can be hidden.
> 
> Testing this with the ld64 in Xcode 5 linking clang reduces the number of
> exported symbols from 21053 to 19049.

Hey, Rafael.  Sorry to dredge up old-ish history.  This is a great idea, but:

> +          if (!GlobalStatus::analyzeGlobal(GV, GS) && !GS.IsCompared)
> +            CanBeHidden = true;

This doesn’t seem to be a complete list of conditions where this is safe.  For a
mutable object, either a load or a store could require the object to be uniqued
across dynamic library boundaries to get the right semantics.

Actually, I’m not sure what uses a mutable linkonce_odr object could possibly
have that would allow it to be hidden.

Of course, for an immutable object (like a Function or a const GlobalVariable),
loads and stores don’t matter; and it’s always allowed if unnamed_addr is
present.

Simple clang test case:
  inline int foo() {
    static int CallCount = 0;
    return CallCount++;
  }

  int next() {
    return foo();
  }

	.section	__DATA,__datacoal_nt,coalesced
	.globl	__ZZ3foovE9CallCount    ## @_ZZ3foovE9CallCount
	.weak_def_can_be_hidden	__ZZ3foovE9CallCount
	.align	2
__ZZ3foovE9CallCount:
	.long	0                       ## 0x0

John.