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

[Rafael Avila de Espindola via llvm-commits]

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