[llvm-dev] Filter optimization remarks by the hotness of the code region
Adam Nemet via llvm-dev
llvm-dev at lists.llvm.org
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
> 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!
> Thanks again,
>>> 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,
>>> ----- 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
>>>> 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
>>>> 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
>>>> diagnostics handler that will only forward to the original handler
>>>> if the region of code is considered hot. This will be installed
>>>> 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
>>>>  http://lists.llvm.org/pipermail/cfe-dev/2016-April/048526.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...
More information about the llvm-dev