[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 4 17:11:52 PDT 2016
Sure. The vectorizer has LoopVectorizeWithBlockFrequency which was meant to adapt the aggressiveness of the vectorizer to the hotness of the code. I think it got turned off by default because at the time BFI didn’t really provide a good measure of hotness. This should probably be looked at again especially if as a result we could turn on vectorization *with versioning* for -Os.
Also just to be clear the main use case is to apply -Rpass-misssed/-Rpass-analysis with PGO and see why we miss in hot regions.
> On May 4, 2016, at 4:54 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> I think it is a good idea, and it reminds me a discussion about Polly at the last llvm-dev meeting, where we considered limiting compile-time impact by running polly only the code that is deemed to be "hot".
> There could be the same kind of logic for things like LoopVersioningLICMPass, or specific optimizations like maybe the vectorization: if the remark is not relevant because the user should not care about this loop, why does the optimizer care in the first place?
>> On May 4, 2016, at 11:12 AM, Adam Nemet via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 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.
>>  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
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
More information about the llvm-dev