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

[Adrian Prantl via llvm-commits]

> On Aug 1, 2019, at 10:33 AM, vsk at apple.com wrote:
> 
> 
> 
>> On Aug 1, 2019, at 10:27 AM, Adrian Prantl <aprantl at apple.com> wrote:
>> 
>> 
>> 
>>> On Aug 1, 2019, at 10:25 AM, Djordje Todorovic <Djordje.Todorovic at rt-rk.com> wrote:
>>> 
>>> I agree that the llvm-dwarfdump already has similar stats, but maybe it is worth of having a tool (maybe this can exist like a llvm-dwarfdump subtool) that reports some kind of verbose output and calculation on the debug location generated. If we want to have some observation only on the location list we can just add a new option to the subtool (i.e. the one for ignoring entry values), rather then putting new fields in to the existing llvm-dwarfdump statistic.
>> 
>> I'm not sure I follow, adding new fields to llvm-dwarfdump --statistics is cheap, what are we gaining be having it a separate tool?
> 
> I think the value of the proposed locstats (sub)tool comes from its pretty-printing support and its bucketing of location coverage by decile. There is a substantial functionality overlap with dwarfdump --statistics, though, so I think a good way to surface those new features might be with a flag (e.g. `llvm-dwarfdump --statistics --format=[json (default) | pretty]`).

Ah interesting. I forgot that the pretty-printing functionality I had in my original implementation never made it upstream. You can see that collectStatsForObjectFile has all the necessary support to implement a non-JSON printer, but it currently it only prints to the llvm::dbgs() channel. I'd be very much in favor to add a human-readable output option since this is very useful for interactive use.

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190801/b4b01d0f/attachment.html>