llvm dev - Jun 2017 - Next steps for optimization remarks?

> On Wed, Jun 28, 2017 at 8:13 AM, Hal Finkel <hfinkel at anl.gov>
wrote:
>
> I don't object to adding some kind of filtering option, but in general
it won't help. An important goal here is to provide analysis (and other)
tools to users that present this information at a higher level. The users
won't, and shouldn't, know exactly what kinds of messages the tools use.
This is already somewhat true for llvm-opt-report, and will be even more true in
the future.
Ah, I see, that makes sense. Thanks!
> On Tue, Jun 20, 2017 at 1:50 AM, Adam Nemet <anemet at apple.com>
wrote:
>
> We desperately need a progress bar in opt-viewer.  Let me know if you want
to add it otherwise I will.  I filed llvm.org/PR33522 for this.
>
> In terms of improving the performance, I am pretty sure the bottleneck is
still YAML parsing so:
>
> - If PGO is used, we can have a threshold to not even emit remarks on cold
code, this should dramatically improve performance, llvm.org/PR33523
> - I expect that some sort of binary encoding of YAML would speed up parsing
but I haven’t researched this topic yet...
I added progress indicators in https://reviews.llvm.org/D34735, and it
seems like it takes a while for the Python scripts to read some of the
larger YAML files produced for my program. I'll try to look into
binary YAML encoding later this week.

A threshold preventing remarks from being emitted on cold code sounds
good to me as well. Hal, do you agree, or is this also something that
tools at a higher level should be responsible for ignoring?

- Brian Gesiak

On 06/28/2017 01:56 PM, Brian Gesiak wrote:
>> On Wed, Jun 28, 2017 at 8:13 AM, Hal Finkel <hfinkel at anl.gov>
wrote:
>>
>> I don't object to adding some kind of filtering option, but in
general it won't help. An important goal here is to provide analysis (and
other) tools to users that present this information at a higher level. The users
won't, and shouldn't, know exactly what kinds of messages the tools use.
This is already somewhat true for llvm-opt-report, and will be even more true in
the future.
> Ah, I see, that makes sense. Thanks!
>
>> On Tue, Jun 20, 2017 at 1:50 AM, Adam Nemet <anemet at apple.com>
wrote:
>>
>> We desperately need a progress bar in opt-viewer.  Let me know if you
want to add it otherwise I will.  I filed llvm.org/PR33522 for this.
>>
>> In terms of improving the performance, I am pretty sure the bottleneck
is still YAML parsing so:
>>
>> - If PGO is used, we can have a threshold to not even emit remarks on
cold code, this should dramatically improve performance, llvm.org/PR33523
>> - I expect that some sort of binary encoding of YAML would speed up
parsing but I haven’t researched this topic yet...
> I added progress indicators in https://reviews.llvm.org/D34735, and it
> seems like it takes a while for the Python scripts to read some of the
> larger YAML files produced for my program. I'll try to look into
> binary YAML encoding later this week.
Sounds good.
>
> A threshold preventing remarks from being emitted on cold code sounds
> good to me as well. Hal, do you agree, or is this also something that
> tools at a higher level should be responsible for ignoring?
I agree that this makes sense. Tools can also threshold at a higher 
level, but this kind of generic filtering can be done without exposing 
users to any unnecessary implementation details.

  -Hal
>
> - Brian Gesiak
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

Please excuse all the questions! Circling back to this:
> On Tue, Jun 20, 2017 at 1:50 AM, Adam Nemet <anemet at apple.com>
wrote:
>
> I expect that some sort of binary encoding of YAML would speed up parsing
but I haven’t researched this topic yet...
I was under the impression that YAML had some sort of standard binary
encoding format, sort of like JSON and BSON [1], but this doesn't
appear to be the case. Did you have something specific in mind here,
or did you mean having optimization remarks optionally emit a
different, non-human-readable format? If so, MessagePack [2] or
protocol buffers [3] appear to be widely used.

[1] http://bsonspec.org
[2] http://msgpack.org/index.html
[3] https://developers.google.com/protocol-buffers/

- Brian Gesiak

> On Jun 28, 2017, at 8:56 PM, Brian Gesiak <modocache at gmail.com>
wrote:
> 
>> On Wed, Jun 28, 2017 at 8:13 AM, Hal Finkel <hfinkel at anl.gov>
wrote:
>> 
>> I don't object to adding some kind of filtering option, but in
general it won't help. An important goal here is to provide analysis (and
other) tools to users that present this information at a higher level. The users
won't, and shouldn't, know exactly what kinds of messages the tools use.
This is already somewhat true for llvm-opt-report, and will be even more true in
the future.
> 
> Ah, I see, that makes sense. Thanks!
> 
>> On Tue, Jun 20, 2017 at 1:50 AM, Adam Nemet <anemet at apple.com>
wrote:
>> 
>> We desperately need a progress bar in opt-viewer.  Let me know if you
want to add it otherwise I will.  I filed llvm.org/PR33522 for this.
>> 
>> In terms of improving the performance, I am pretty sure the bottleneck
is still YAML parsing so:
>> 
>> - If PGO is used, we can have a threshold to not even emit remarks on
cold code, this should dramatically improve performance, llvm.org/PR33523
>> - I expect that some sort of binary encoding of YAML would speed up
parsing but I haven’t researched this topic yet...
> 
> I added progress indicators in https://reviews.llvm.org/D34735, and it
> seems like it takes a while for the Python scripts to read some of the
> larger YAML files produced for my program.
You may want look at these files with opt-stats and see what type of remarks are
on the top of the list.  If they are missed remarks, we may need to work harder
to remove false positives.

Adam
> I'll try to look into
> binary YAML encoding later this week.
> 
> A threshold preventing remarks from being emitted on cold code sounds
> good to me as well. Hal, do you agree, or is this also something that
> tools at a higher level should be responsible for ignoring?
> 
> - Brian Gesiak