llvm dev - Dec 2016 - Enabling statistics in release builds / static constructors

Analyzing a compilers behavior and timings is an important tool to track code
size and compile time regressions. One of the tools we would like to use are
Statistic variable (llvm/include/ADT/Statistic.h). However today I cannot enable
them in release builds without a performance hits because the lazy
initialisation present forces a memory fence on every single increment of the
statistic variable. This is trivial to fix: Do the initialization in the
constructor. See https://reviews.llvm.org/D27724

I am writing this mail because I expect opposition against introducing static
constructors. Looking at previous discussions it is obvious that a lot of static
constructor usage is bad as it promotes global state that should better be put
into LLVMContext.
However lazily initializing the Statistic variables makes them in no way less
static, we just somewhat delay the initialization at the price of a heavy
performance penalty on usage. I don't see a better alternative at the
moment.

- Matthias

Given that LLVM has so many auto-registration systems (cl::opt, target
registry, pass registry, statistics, I'm sure there's more), maybe we
should spend the time to build an auto-registration system that doesn't
involve static constructors?

It needs custom code for every supported object file format, and is hard to
get right when DSOs are involved, but in the long run it's probably worth
fixing this problem once and for all.

On Tue, Dec 13, 2016 at 11:53 AM, Matthias Braun via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Analyzing a compilers behavior and timings is an important tool to track
> code size and compile time regressions. One of the tools we would like to
> use are Statistic variable (llvm/include/ADT/Statistic.h). However today
> I cannot enable them in release builds without a performance hits because
> the lazy initialisation present forces a memory fence on every single
> increment of the statistic variable. This is trivial to fix: Do the
> initialization in the constructor. See https://reviews.llvm.org/D27724
>
> I am writing this mail because I expect opposition against introducing
> static constructors. Looking at previous discussions it is obvious that a
> lot of static constructor usage is bad as it promotes global state that
> should better be put into LLVMContext.
> However lazily initializing the Statistic variables makes them in no way
> less static, we just somewhat delay the initialization at the price of a
> heavy performance penalty on usage. I don't see a better alternative at
the
> moment.
>
> - Matthias
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/395699a8/attachment.html>

> On Dec 13, 2016, at 12:56 PM, Reid Kleckner <rnk at google.com>
wrote:
> 
> Given that LLVM has so many auto-registration systems (cl::opt, target
registry, pass registry, statistics, I'm sure there's more), maybe we
should spend the time to build an auto-registration system that doesn't
involve static constructors?
I would volunteer to do the work, however this obviously needs some consensus
first on how that would look.
> 
> It needs custom code for every supported object file format, and is hard to
get right when DSOs are involved, but in the long run it's probably worth
fixing this problem once and for all.
I assume you are thinking about creating custom linker sections with list of
init functions; Similar to the existing constructors sections but running at a
time controlled by llvm code. While the compiler/linker nerd in me would love
doing that, I could see this being very tricky to pull off consistenly on all
platforms.

We should not forget that there is a portable and proven solution: Just write
the code!
So here comes the strawman:


static Statistic NumBlips("blips");
static cl::opt MyOpt("my-cool-option", cl::desc("bla"));
static cl::opt AnotherOpt("bla", cl::desc("foo bar"));
// Note that the constructors of Statistic and cl::opt would be reworked to be
pure constexpr and do not run any code

static void init_globals() {
  NumBlips.init();
  MyOpt.init();
  AnotherOpt.init();
}
// Note that the init_globals() function is pretty mechanical so hopefully easy
to understand and maintain.

We have to call init_gloabals somewhere early:
- Put an init_globals() call into code that runs early.
- We already have a lot of early running functions called initializeXXXPass()
which we can use for this
- For the remaining files we probably have to export init_globals() and call it
from some common place of the library.

If someone comes up a with working solution for putting initializers into a
section we can later replace the
init_globals() function with that so the refactoring work to split into
constexpr constructor and init() is not wasted either way!

- Matthias