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

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>

I don’t believe it is any more work (except the registry infrastructure) to do
than you strawman proposal.
> On Dec 13, 2016, at 3:36 PM, Matthias Braun <mbraun at apple.com>
wrote:
> 
> 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
<mailto: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/b21853b0/attachment.html>

But it is more work: My strawman proposal only needs a very mechanical change of
adding one xxx.init(); line for each global. Putting the variables into context
classes is more involved: You have to actually decide on the appropriate context
class for each of them and you will face lots of small helper functions outside
of classes that simply have no appropriate context at hand.

- Matthias
> On Dec 13, 2016, at 3:40 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> 
> I don’t believe it is any more work (except the registry infrastructure) to
do than you strawman proposal.
>> On Dec 13, 2016, at 3:36 PM, Matthias Braun <mbraun at apple.com
<mailto:mbraun at apple.com>> wrote:
>> 
>> 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
<mailto: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/92282700/attachment-0001.html>