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

Matthias Braun via llvm-dev
Tue, 13 Dec 2016 23:36:35 -0000

I don't agree with an ideological "burn and remove all the
globals" stance. For one thing that means heavy rewriting (we would need to
move all the Statistic variable into classes somewhere, pass around way more
contexts). I am NOT volunteering for that part of work.

- Matthias

> On Dec 13, 2016, at 3:34 PM, Chris Bieneman <beanz at apple.com>
wrote:
>
> 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
<mailto: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/eb0a31ff/attachment.html>