[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?
> -- 
> Mehdi
>> 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 [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
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

More information about the llvm-dev mailing list