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

Chris Bieneman via llvm-dev
Tue, 13 Dec 2016 23:34:03 -0000

The intention with cl::opt was to use the singleton as a transitionary measure
only. The end goal was to move option storage into the {MC|LLVM}Context.

-Chris

> On Dec 13, 2016, at 3:32 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
>>
>> On Dec 13, 2016, at 3:28 PM, Matthias Braun <mbraun at apple.com
<mailto: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/77609c70/attachment.html>