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

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>

Well for one you’re snippet includes a `static void init_globals() {` which
definitely can be “static” and it is quite unclear to me how you’re gonna
trigger the registration for it.
> On Dec 13, 2016, at 3:43 PM, Matthias Braun <mbraun at apple.com>
wrote:
> 
> 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
<mailto: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/a7434d79/attachment.html>

As I wrote the trick here is sneak the initGlobals() into the places where we do
pass registration which should get you a big part of the way. For the remaining
cases you have to add a few functions and call them from init() like functions
which we have all over llvm anyway because of pass registration.

- Matthias
> On Dec 13, 2016, at 3:46 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> 
> Well for one you’re snippet includes a `static void init_globals() {` which
definitely can be “static” and it is quite unclear to me how you’re gonna
trigger the registration for it.
> 
>> On Dec 13, 2016, at 3:43 PM, Matthias Braun <mbraun at apple.com
<mailto:mbraun at apple.com>> wrote:
>> 
>> 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 <mailto: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/04b97c22/attachment.html>