search for: profilesummaryinfo

Hello, I want to use ProfileSummaryInfo in a class which is not a LLVM pass like TargetFrameLowering class (lib/CodeGen/TargetFrameLoweringImpl.cpp) one way I know to get ProfileSummaryInfo is getAnalysis<ProfileSummaryInfoWrapperPass>().getPSI(M); but I can't use this. Is this really possible? Sincerely, Vivek ------------...

Hi all, To implement more profile-guided optimizations, we’d like to use ProfileSummaryInfo (PSI) and BlockFrequencyInfo (BFI) from more passes of various types, under the new pass manager. The following is what we came up with. Would appreciate feedback. Thanks. Issue It’s not obvious (to me) how to best do this, given that we cannot request an outer-scope analysis result from an inne...

Hi, I am working right now on importing based on PGO/FDO data. There is one issue that I found - when we calculate the list of imports, we can't get the ProfileSummaryInfo, which is the best and I think only valid way of checking if callsite/callee is hot (isHotCount()). There are 2 solutions that I come up with Teresa and Easwaran: 1. Add PGO data to summary 2. Replace CalleeInfo::ProfileCount with enum {None, Cold, Hot} computed during computing summary. I like t...

...) https://reviews.llvm.org/D58845 On Fri, Mar 1, 2019 at 12:54 PM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 2/28/19 12:47 AM, Hiroshi Yamauchi via llvm-dev wrote: > > Hi all, > > To implement more profile-guided optimizations, we’d like to use > ProfileSummaryInfo (PSI) and BlockFrequencyInfo (BFI) from more passes of > various types, under the new pass manager. > > The following is what we came up with. Would appreciate feedback. Thanks. > > Issue > > It’s not obvious (to me) how to best do this, given that we cannot request > an out...

...t; On Fri, Mar 1, 2019 at 12:54 PM Fedor Sergeev via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 2/28/19 12:47 AM, Hiroshi Yamauchi via llvm-dev wrote: >> >> Hi all, >> >> To implement more profile-guided optimizations, we’d like to use >> ProfileSummaryInfo (PSI) and BlockFrequencyInfo (BFI) from more passes of >> various types, under the new pass manager. >> >> The following is what we came up with. Would appreciate feedback. Thanks. >> >> Issue >> >> It’s not obvious (to me) how to best do this, given that w...

...t;mailto:llvm-dev at lists.llvm.org>> wrote: >> >> On 2/28/19 12:47 AM, Hiroshi Yamauchi via llvm-dev wrote: >>> Hi all, >>> >>> To implement more profile-guided optimizations, we’d >>> like to use ProfileSummaryInfo (PSI) and >>> BlockFrequencyInfo (BFI) from more passes of various >>> types, under the new pass manager. >>> >>> The following is what we came up with. Would appreciate >>> feedback. Thanks. >>> &...

...y in the IR is written in > the pass pipeline. This would avoid the need to insert > RequireAnalysisPass for PSI before each non-module pass that needs it. > PSI can be technically invalidated but unlikely as PSI is immutable. > If it does, we can insert another RequireAnalysisPass. ProfileSummaryInfo::invalidate always return false, so it does not need any extra handling (as soon as it finds its way into ModuleAnalysisManager). > > - If PGO, conditionally request BFI from the passes that need it. For > (pipelined) loop passes, we need to insert a pass that computes BFI > conditio...

...;> llvm-dev wrote: >>>>> Hi all, >>>>> >>>>> To implement more profile-guided >>>>> optimizations, we’d like to use >>>>> ProfileSummaryInfo (PSI) and >>>>> BlockFrequencyInfo (BFI) from more passes of >>>>> various types, under the new pass manager. >>>>> >>>>> The following is what we came up with. Would >>>...

...On Fri, Sep 2, 2016 at 2:58 PM, Piotr Padlewski > <piotr.padlewski at gmail.com> wrote: > > Hi, > > I am working right now on importing based on PGO/FDO data. There is one > > issue that I found - when we calculate the list of imports, we can't get > the > > ProfileSummaryInfo, which is the best and I > > think only valid way of checking if callsite/callee is hot > (isHotCount()). > > There are 2 solutions that I come up with Teresa and Easwaran: > > > > 1. Add PGO data to summary > > 2. Replace CalleeInfo::ProfileCount with enum {None, C...

...2:58 PM, Piotr Padlewski >> <piotr.padlewski at gmail.com> wrote: >> > Hi, >> > I am working right now on importing based on PGO/FDO data. There is one >> > issue that I found - when we calculate the list of imports, we can't >> get the >> > ProfileSummaryInfo, which is the best and I >> > think only valid way of checking if callsite/callee is hot >> (isHotCount()). >> > There are 2 solutions that I come up with Teresa and Easwaran: >> > >> > 1. Add PGO data to summary >> > 2. Replace CalleeInfo::Profile...

...otr.padlewski at gmail.com> wrote: > >> > Hi, > >> > I am working right now on importing based on PGO/FDO data. There is > one > >> > issue that I found - when we calculate the list of imports, we can't > get > >> > the > >> > ProfileSummaryInfo, which is the best and I > >> > think only valid way of checking if callsite/callee is hot > >> > (isHotCount()). > >> > There are 2 solutions that I come up with Teresa and Easwaran: > >> > > >> > 1. Add PGO data to summary > >>...

Hi David, So I've began doing some implementation on the outlining portion of the code. Currently, I got the partial inliner to outline cold regions (single entry, single exit) of the code, based solely on the existence of ProfileSummaryInfo (ie. profiling data). However, I have some concerns on how this will co-exist with the existing code that peels early returns. The control flow looks something like this: // New Code: find cold regions to outline if (!computeOutliningInfoForColdRegions()) { // If we can't find any cold reg...

...5:5 llvm::function_ref<llvm::LoopAccessInfo const& (llvm::Loop&)>::operator()(llvm::Loop&) const $SRC/llvm-project/llvm/include/llvm/ADT/STLExtras.h:203:5 eliminateLoadsAcrossLoops(llvm::Function&, llvm::LoopInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo*, llvm::ProfileSummaryInfo*, llvm::function_ref<llvm::LoopAccessInfo const& (llvm::Loop&)>) $SRC/llvm-project/llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp:618:53 (anonymous namespace)::LoopLoadElimination::runOnFunction(llvm::Function&) $SRC/llvm-project/llvm/lib/Transforms/Scalar/LoopLoadElimination....

...017 at 10:40 AM, Graham Yiu <gyiu at ca.ibm.com> wrote: Hi David, So I've began doing some implementation on the outlining portion of the code. Currently, I got the partial inliner to outline cold regions (single entry, single exit) of the code, based solely on the existence of ProfileSummaryInfo (ie. profiling data). However, I have some concerns on how this will co-exist with the existing code that peels early returns. The control flow looks something like this: // New Code: find cold regions to outline if (!computeOutliningInfoForColdRegions()) { // If we can't find any c...

...5:5 llvm::function_ref<llvm::LoopAccessInfo const& (llvm::Loop&)>::operator()(llvm::Loop&) const $SRC/llvm-project/llvm/include/llvm/ADT/STLExtras.h:203:5 eliminateLoadsAcrossLoops(llvm::Function&, llvm::LoopInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo*, llvm::ProfileSummaryInfo*, llvm::function_ref<llvm::LoopAccessInfo const& (llvm::Loop&)>) $SRC/llvm-project/llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp:618:53 (anonymous namespace)::LoopLoadElimination::runOnFunction(llvm::Function&) $SRC/llvm-project/llvm/lib/Transforms/Scalar/LoopLoadElimination....

...et experimental PGO driven IPRA work. The idea is to save all register in prolog and restore it in epilog for cold function so that IPRA can propagate some free register to upper region of call graph. For this I changed spill callee saved regs related functions in PrologEpilogInserter pass to pass ProfileSummaryInfo object as parameter so that ultimately I can access it at TargetFrameLowringImpl and override callee saved register details of default regmask. But this also required to change function signature to in target specific code of TargetFrameLowring. This is not sufficient when running with -g flag or...

...gt; >> Hi David, >> >> So I've began doing some implementation on the outlining portion of >> the code. Currently, I got the partial inliner to outline cold regions >> (single entry, single exit) of the code, based solely on the existence of >> ProfileSummaryInfo (ie. profiling data). However, I have some concerns on >> how this will co-exist with the existing code that peels early returns. >> >> The control flow looks something like this: >> >> // New Code: find cold regions to outline >> if (!computeOutlinin...

Hello, My team and I are looking to do some enhancements in the partial inliner in opt. Would appreciate any feedback that folks might have. # Partial Inlining in LLVM opt ## Summary ### Background Currently, the partial inliner searches the first few blocks of the callee and looks for a branch to the return block (ie. early return). If found, it attempts to outline the rest of the

Hello LLVM Developers, Please feel free to send any ideas that you can think to improve current IPRA. I will work on it and if possible I will implement that. Please consider summary of work done during this week. Implementation: ============ The reviews requests has been updated to reflect the reviews. Testing: ===== To get more benefit from IPRA I experimented it with LTO and results

Hello Mentors, I did analyze assembly files generated for IPRA + PGO. (1) I observed that I did not considered the scope of the optimization so changing callee saved register set for non local function is bad because IPRA can not pass this information to other modules. (2) applying this change to indirect function also has no effect because for such case IPRA is currently not able to propagate