[PATCH] D31566: [Support] Make printAllJSONValues public, for custom output.

Matthias Braun via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 3 10:33:29 PDT 2017


MatzeB added a comment.

In https://reviews.llvm.org/D31566#716880, @graydon wrote:

> In https://reviews.llvm.org/D31566#716865, @MatzeB wrote:
>
> > We could go ahead and make this function public for now.
> >
> > However I don't expect this API to be stable. Long term we really should move away from a global list of timers accessed by TimerGroup. In fact I am planning changes to the statistics system right now. Are you prepared to loose the function again in a few weeks?
>
>
> I guess. We use it in swift, so I'd prefer you not just break swift's usage! But if you're modifying it in a way that's still usable by outside clients, we can probably adapt. What do you have planned?


The motivation on our side is that we want statistics (I think of timers as being part of statistics) per module or per function and not just per compiler invocation. A global timer list probably won't help here. I hope we can move to some model where you have a statistic stream object maintaining the current context (context being module/function in our case) that you send statistic events to (= timer or other statistic values). Unfortunately this is all early stage planing/talking to people right now so I cannot give you any details.

Anyway without even the new system in place I cannot say much about how to transition to it... It'll surely be usably by code outside of LLVM, I guess we have to discuss how to transition users of the old system when we we know how the new one looks like.

> 
> 
>> Also the fact that you need to call this function seems suspicious to me. Could you elaborate a bit why PrintStatisticsJSON() wasn't enough for your use case?
> 
> Because PrintStatisticsJSON() prints an opening- and close-brace, meaning it cannot be used as part of another printing function (at least not without introducing a superfluous level of JSON-object-nesting).
> 
> The root problem is that LLVM statistics are enabled/disabled at compile time, by a #define that I'm not really comfortable switching globally (they wind up being used pervasively in clang and llvm, and they cost a global lock + mfence every time they're incremented). So while I can rely on the _timer_ facility always being present, the statistics facility is present or absent depending on whether I'm using an asserts build. Thus for any counters that I want to "always measure", even in release builds (independent of asserts) I need to count them independently and place their output in the place where LLVM would normally put its statistics output.

Sounds like we have very similar problems. Unfortunately my attempts at making them cheaper failed with the current system because people rejected global constructors/variables (which however is the only way in the current system), see also http://lists.llvm.org/pipermail/llvm-dev/2016-December/108088.html


https://reviews.llvm.org/D31566





More information about the llvm-commits mailing list