[llvm-dev] Enabling statistics in release builds / static constructors

[Mehdi Amini via llvm-dev]

> On Dec 13, 2016, at 3:28 PM, Matthias Braun <mbraun at apple.com> wrote:
> 
>> 
>> On Dec 13, 2016, at 3:27 PM, Matthias Braun <mbraun at apple.com <mailto:mbraun at apple.com>> wrote:
>> 
>>> 
>>> On Dec 13, 2016, at 3:23 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>>> 
>>>> 
>>>> On Dec 13, 2016, at 1:22 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>> 
>>>> 
>>>>> On Dec 13, 2016, at 12:56 PM, Reid Kleckner <rnk at google.com <mailto: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!
>>> 
>>> I agree, and there was a proposal in the past for cl::opt (I believe from Chris B.). The idea would be to have explicit registration (from the pass ctor for instance) and the storage for the options being hold in the context somehow (old memories, not sure about the details).
>>> 
>>> CC Chris who likely has more information (and possibly pointers).
>> 
>> You probably mean:
>> http://web.archive.org/http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075886.html <http://web.archive.org/http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075886.html> [1]
>> and
>> http://reviews.llvm.org/D5389 <http://reviews.llvm.org/D5389>
>> 
>> but I fail to see how that helps Statistic variables which are still global.
> 
> Admittedly the "static void registerOptions()" part of that patch appears to have the same/similar role than the "initGlobals()" I proposed.
> 

Right, basically there wouldn’t be any global variables, that would apply to statistics as well. The way Chris did it somehow was to use a singleton registry for this. 
You could do the same for statistic and have any component that needs to use a statistic to get a reference to it from the registry on initialization (pass ctor for example). You wouldn’t any other registration code, because we don’t need to register early statistic on the contrary to cl::opt.

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/91bf949c/attachment-0001.html>