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

Wed May 11 10:45:32 PDT 2016

> On May 11, 2016, at 3:37 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- 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.

I think this all makes sense.  So I guess the steps are:

1. YAML support for the existing remarks
2. Add optional relative hotness to the opt-remark API
3. Exposed relative hotness in the YAML output

Are you working on 1 or should I get started?

There was another issue that came up while discussing this with John McCall.  We could have a pretty large number of such remarks.  I imagine that if the post-processing is performed by the external tool, it may be useful to effectively enable all optimization remarks (i.e. -Rpass/-Rpass-missed/-Rpass-analysis=loop-vectorize/inline/etc.).  For large programs this may not be feasible and we may need to locally filter the remarks in LLVM.  This however seems like a somewhat orthogonal issue that we could probably postpone for now.

Thanks for your input!
Adam

> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160511/c97289d6/attachment.html>