[llvm-dev] RFC: Getting ProfileSummaryInfo and BlockFrequencyInfo from various types of passes under the new pass manager

Fedor Sergeev via llvm-dev llvm-dev at lists.llvm.org
Sat Mar 2 02:13:50 PST 2019


On 3/2/19 2:38 AM, Hiroshi Yamauchi wrote:
>
>>     Conditional BFI
>>     We could consider adding a conditional BFI analysis that is a
>>     wrapper around BFI and computes BFI only if profiles are
>>     available (either checking the module has profile summary or
>>     depend on the PSI.) With this, we wouldn’t need to conditionally
>>     build pass pipelines and may work for the new pass manager. But a
>>     similar wouldn’t work for the old pass manager because we cannot
>>     conditionally depend on an analysis under it.
>     There is LazyBlockFrequencyInfo.
>     Not sure how well it fits this idea.
>
>
> Good point. LazyBlockFrequencyInfo seems usable with the old pass 
> manager (save unnecessary BFI/BPI) and would work for function passes. 
> I think the restriction still applies - a loop pass cannot still 
> request (outer-scope) BFI, lazy or not, new or old (pass manager).
You would need to explicitly require it (or/and add to 
LoopStandardAnalysisResult) and teach loop passes to preserve it.
Preserving LazyBFI might be as simple as resetting it all, yet the 
overall idea of this LAzyBFI thing seems to be more or
less duplicating what analysis managers are doing in new pass manager.

Here is a comment from LazyBFI's header:
   /// Note that it is expected that we wouldn't need this functionality 
for the
   /// new PM since with the new PM, analyses are executed on demand.

:)

regards,
   Fedor.

> Another assumption is that it'd be cheap and safe to unconditionally 
> depend on PSI or check the module's profile summary.
>
>
>     regards,
>       Fedor.
>
>>
>>
>>     [1] We cannot call AnalysisManager::getResult for an outer scope
>>     but only getCachedResult. Probably because of potential
>>     pipelining or concurrency issues.
>>     [2] For example, potentially breaking up multiple pipelined loop
>>     passes and insert RequireAnalysisPass<BlockFrequencyAnalysis> in
>>     front of each of them.
>>     [3] For example, -fprofile-instr-use and -fprofile-sample-use
>>     aren’t present in ThinLTO post link builds.
>>     [4] For example, we could check whether the module has the
>>     profile summary metadata annotated when building pass pipelines
>>     but we don’t always pass the module down to the place where we
>>     build pass pipelines.
>>     [5] By inserting RequireAnalysisPass<ProfileSummaryInfo> after
>>     the PGOInstrumentationUse and the SampleProfileLoaderPass passes
>>     (and around the PGOIndirectCallPromotion pass for the Thin LTO
>>     post link pipeline.)
>>     [6] For example, the context-sensitive PGO.
>>     [7] Directly calling its constructor along with the dependent
>>     analyses results, eg. the jump threading pass.
>>
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     llvm-dev at lists.llvm.org  <mailto:llvm-dev at lists.llvm.org>
>>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

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


More information about the llvm-dev mailing list