[llvm-dev] Filter optimization remarks by the hotness of the code region

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Adam Nemet" <anemet at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev (llvm-dev at lists.llvm.org)" <llvm-dev at lists.llvm.org>
> Sent: Wednesday, May 11, 2016 1:15:42 AM
> Subject: Re: Filter optimization remarks by the hotness of the code region
> 
> Hi Hal,
> 
> > On May 10, 2016, at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> > 
> > Hi Adam,
> > 
> > I think would be a really useful feature to have. I don't think
> > that the backend should be responsible for filtering, but should
> > pass the relative hotness information to the frontend. Given that
> > these diagnostics are not just going to be used for -Rpass and
> > friends, but also for generating reports by other tools (see the
> > discussion around D19678, for example), I think it is important to
> > allow the frontend to filter.
> 
> I am not sure I follow, can you please elaborate.  Are you saying
> that for example in the listing use case we don’t want the filtered
> diagnostics?  In other words it should be up to the remark handler
> to decide whether it wants filtered or unfiltered remarks?

We might or might not want them. The user might want to select different ratios and filters.
 
> > The frontend, or other tool, might also want to collect information
> > from different compilation jobs to provide the user with an
> > overall ranking.
> 
> Strictly speaking about PGO, the different compilation jobs get the
> same PGO with the aggregated profile, thus the hotness calculated
> should be global.  I am not sure why an extra aggregation step is
> necessary.

I agree. However, I think that the frontend might employ a combination of factors in deciding what information to present. We might, for example, have pick different hotness thresholds for different kinds of remarks.

Especially since we're likely going with a design for the optimization reports where the frontend just creates some YAML files with the diagnostic information, and then a separate tool processes the files to produce reports, I think that we should give those tools the maximum about of practical flexibility. Such a tool might provide the user with non-trivial filtering options.

Thanks again,
Hal

> 
> > The default diagnostic, furthermore, does not provide enough
> > information to identify a code "region". I think that the pass
> > generating the diagnostic needs to provide the information,
> > however, we could certainly create some utility functions that
> > take a pointer to the BFI analysis and a Value* that can do the
> > right thing in most simple cases.
> 
> Good point.
> 
> Thanks for your feedback.
> 
> Adam
> 
> > 
> > Thanks again,
> > Hal
> > 
> > ----- Original Message -----
> >> From: "Adam Nemet" <anemet at apple.com>
> >> To: "llvm-dev (llvm-dev at lists.llvm.org)" <llvm-dev at lists.llvm.org>
> >> Cc: "Hal Finkel" <hfinkel at anl.gov>
> >> Sent: Wednesday, May 4, 2016 1:12:17 PM
> >> Subject: Filter optimization remarks by the hotness of the code
> >> region
> >> 
> >> This idea came up a few times recently [1][2] so I’d like start
> >> prototyping it.  To summarize, we can emit optimization remarks
> >> using the -Rpass* options.  These are currently emitted by
> >> optimizations like vectorization[3], unrolling, inlining and since
> >> last week loop distribution.
> >> 
> >> For large programs however this can amount to a lot of diagnostics
> >> output to sift through.  Filtering this by the hotness of the
> >> region
> >> can help to focus the user on performance opportunities that are
> >> likely to pay off.
> >> 
> >> The approach I am thinking of taking is to install a wrapper as
> >> the
> >> diagnostics handler that will only forward to the original handler
> >> if the region of code is considered hot.  This will be installed
> >> by
> >> a new pass that will use BlockFrequencyInfo to determine the top N
> >> hot regions.
> >> 
> >> This is at very early stage right now.  I would appreciate any
> >> feedback.
> >> 
> >> Thanks,
> >> Adam
> >> 
> >> [1]
> >> http://lists.llvm.org/pipermail/llvm-dev/2016-April/098492.html
> >> [2] http://lists.llvm.org/pipermail/cfe-dev/2016-April/048526.html
> >> [3]
> >> http://blog.llvm.org/2014/11/loop-vectorization-diagnostics-and.html
> > 
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory