[lld] r312796 - Currently lld creates a single section to collect all commons. There is no way

[Shoaib Meenai via llvm-commits]

I can't reproduce the slowdown anymore :( I'm measuring by running the link in
question 16 times with `time` and taking the average of the total time
reported. Yesterday, I was consistently seeing the 20% slowdown I mentioned.
Today that difference has dropped to 2%. Perhaps my runs yesterday got unlucky
with CPU load from other processes or something similar.

Sorry for the false alarm. I'll still try to switch my library to using
-fno-common though, just for general cleanliness. Thanks for all the replies!

On 9/12/17, 2:51 PM, "Rafael Avila de Espindola" <rafael.espindola at gmail.com> wrote:

    Shoaib Meenai <smeenai at fb.com> writes:
    
    > It's written in C, and it has 325 common symbols.
    >
    > I only read up on common symbols today, so please correct me if my
    > understanding is off. From what I've read, you'll end up with a common symbol
    > in your object file if you have an uninitialized non-static global variable,
    > e.g. (in the global scope):
    >
    > int x;
    >
    > If you mark the variable static, or if you explicitly zero-initialize it,
    > it'll end up in bss instead of COMMON. You can also use -fno-common to force
    > the use of bss, and C++ does so by default.
    >
    > I understand that COMMON symbols were originally devised to deal with people
    > writing `int x` instead of `extern int x` in headers. My library doesn't have
    > that problem; the `int x` form is used only in source files, and the intent is
    > to define a variable and have it be automatically zero-initialized. I was
    > hoping that if a variable was preceded by an extern declaration, e.g.
    >
    > extern int x;
    > ...
    > int x;
    >
    > the compiler would place it in bss instead of COMMON, but that doesn't appear
    > to be the case.
    >
    > I'll try compiling my sources with -fno-common. This definitely seems like
    > something a lot of libraries could run into though, since it looks like all
    > you need to trigger it is an uninitialized global variable.
    
    Your understanding is correct. As Rui points out, allocating 325
    sections cannot be directly slowing down lld so much.
    
    My first guess would be that by making DefinedCommon larger the patch
    could have increased the size of Symbol, but that was not the case since
    SharedSymbol was still bigger.
    
    How stable is the benchmark across lld versions? What time do you get
    with top of tree?
    
    Cheers,
    Rafael