Matthias Braun via llvm-dev
2016-Dec-13 19:53 UTC
[llvm-dev] 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
Reid Kleckner via llvm-dev
2016-Dec-13 20:56 UTC
[llvm-dev] Enabling statistics in release builds / static constructors
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>
Matthias Braun via llvm-dev
2016-Dec-13 21:22 UTC
[llvm-dev] Enabling statistics in release builds / static constructors
> 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
Reasonably Related Threads
- Enabling statistics in release builds / static constructors
- Enabling statistics in release builds / static constructors
- Enabling statistics in release builds / static constructors
- Enabling statistics in release builds / static constructors
- Enabling statistics in release builds / static constructors