[llvm-dev] Filter optimization remarks by the hotness of the code region
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Wed May 11 03:37:49 PDT 2016
----- 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
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.
> > 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.
> > 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  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, 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
> >> 
> >> http://lists.llvm.org/pipermail/llvm-dev/2016-April/098492.html
> >>  http://lists.llvm.org/pipermail/cfe-dev/2016-April/048526.html
> >> 
> >> http://blog.llvm.org/2014/11/loop-vectorization-diagnostics-and.html
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev