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

Hiroshi Yamauchi via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 4 11:07:58 PST 2019


On Sat, Mar 2, 2019 at 2:13 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote:

> 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 t
> he 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.
>
> :)
>

Yes, we could actually request LazyBFI from a loop pass under the old pass
manager.



>
> 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 listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> 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/20190304/f95a2910/attachment-0001.html>


More information about the llvm-dev mailing list