[PATCH] D65585: WIP: [llvm-locstats] Add the llvm-locstats tool

Wed Aug 7 09:10:48 PDT 2019

> On Aug 7, 2019, at 2:11 AM, Djordje Todorovic <djordje.todorovic at rt-rk.com> wrote:
> 
> Thank you all for valuable comments! I was away for a few days and sorry for the late response.
> 
> Vedant, Adrian,
> 
>>>> I take your point about not wanting to clutter up llvm-dwarfdump --statistics output.
>>>> 
>>>> I'll note that, beyond code sharing, there are significant benefits to emitting all `locstats` information using the existing `--statistics` option:
>>>> 
>>>> 1) We can check in a simple script in utils/ to pretty-print the `--statistics` JSON output, such that we get exactly what is emitted by the `locstats` tool today.
>>>> 
>>>> 2) Emitting stats in JSON is great for continuous integration jobs that track debug info quality over time. It'd be great to include the metrics reported by `locstats` in these jobs.
>>> 
>>> And I should point out that this is not a hypothetical scenario. This job:
>>> 
>>> http://green.lab.llvm.org/green/view/LLDB/job/clang-3.4-debuginfo-statistics/
>>> 
>>> Pushes data into:
>>> 
>>> http://lnt.llvm.org/db_default/v4/nts/machine/1357
>>> 
>>> which generates graphs like:
>>> 
>>> http://lnt.llvm.org/db_default/v4/nts/graph?plot.0=1357.1607043.4&highlight_run=127815
>>> 
>>> several times per hour. Any new JSON fields show up there without any extra manual intervention.
> 
> This is very helpful and I agree we could add a script into the 'utils/' that can do the 'locstats' job instead!
> 
> I just wanted to emphasize (and correct my self if I was expressed in a wrong way) that I did not want to say that adding extra fields to the 'llvm-dwarfdump' stats is expensive, but I wanted to say that having a separate (sub)tool (or the utils script) improves the stats reporting in a human (user) friendly way (by pretty-printing and encapsulating the locations stats job).

Yeah my main point was to encourage everyone to add generally useful statistics to llvm-dwarfdump. I kind of like the idea of collecting the raw data with llvm-dwarfdump and then having (e.g., a Python-based) tool to post-process the JSON output to compute derived data, make it human-readable and allow for interactive queries and such. I could imagine that combining the various --filter options with --statistics could turn llvm-dwarfdump into an even more useful tool for more interactive work. I also wouldn't mind adding an option for human-readable output to --statistics, since dwarfdump is meant to be an interactive tool, too. So I'm fine with either adding the code to dwarfdump or to a script-driver in utils/.

-- adrian

> 
> Best regards,
> Djordje
> 
> 
> On 5.8.19. 18:49, Adrian Prantl wrote:
>> 
>> 
>>> On Aug 2, 2019, at 6:10 PM, vsk at apple.com <mailto:vsk at apple.com> wrote:
>>> 
>>> Hi Djordje,
>>> 
>>> I take your point about not wanting to clutter up llvm-dwarfdump --statistics output.
>>> 
>>> I'll note that, beyond code sharing, there are significant benefits to emitting all `locstats` information using the existing `--statistics` option:
>>> 
>>> 1) We can check in a simple script in utils/ to pretty-print the `--statistics` JSON output, such that we get exactly what is emitted by the `locstats` tool today.
>>> 
>>> 2) Emitting stats in JSON is great for continuous integration jobs that track debug info quality over time. It'd be great to include the metrics reported by `locstats` in these jobs.
>> 
>> And I should point out that this is not a hypothetical scenario. This job:
>> 
>> http://green.lab.llvm.org/green/view/LLDB/job/clang-3.4-debuginfo-statistics/
>> 
>> Pushes data into:
>> 
>> http://lnt.llvm.org/db_default/v4/nts/machine/1357
>> 
>> which generates graphs like:
>> 
>> http://lnt.llvm.org/db_default/v4/nts/graph?plot.0=1357.1607043.4&highlight_run=127815
>> 
>> several times per hour. Any new JSON fields show up there without any extra manual intervention.
>> 
>> -- adrian