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

[Hiroshi Yamauchi via llvm-dev]

On Mon, Mar 4, 2019 at 11:07 AM Hiroshi Yamauchi <yamauchi at google.com>
wrote:

>
>
> 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.
>

And we could avoid running unnecessary BFI for non-PGO cases.


>
>
>
>>
>> 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/e64ec61e/attachment.html>