search for: bfy

(Resending after removing llvmdev at cs.uiuc.edu and using llvm-dev at lists.llvm.org) On Mon, Dec 7, 2015 at 3:08 PM, Easwaran Raman <eraman at google.com> wrote: > Hi Philip, > > Is there any update on this? I've been sending patches to get rid of the > callee hotness based inline hints from the frontend and move the logic to > the inliner. The next step is to use

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 inner-scope

On 3/4/19 10:49 PM, Hiroshi Yamauchi wrote: > > > On Mon, Mar 4, 2019 at 10:55 AM Hiroshi Yamauchi <yamauchi at google.com > <mailto:yamauchi at google.com>> wrote: > > > > On Sat, Mar 2, 2019 at 12:58 AM Fedor Sergeev > <fedor.sergeev at azul.com <mailto:fedor.sergeev at azul.com>> wrote: > > > > On 3/2/19 2:38 AM,

On Sat, Mar 2, 2019 at 12:58 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > > On 3/2/19 2:38 AM, Hiroshi Yamauchi wrote: > > Here's a sketch of the proposed approach for just one pass (but imagine > more) > > 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>

Here's a sketch of the proposed approach for just one pass (but imagine more) 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

On Thu, Dec 10, 2015 at 4:51 PM, Philip Reames <listmail at philipreames.com> wrote: > > > On 12/10/2015 04:29 PM, Xinliang David Li wrote: >> >> On Thu, Dec 10, 2015 at 4:00 PM, Philip Reames >> <listmail at philipreames.com> wrote: >>> >>> Given I didn't get any response to my original query, I chose not to >>> invest

Overall seems fine to me. On 3/11/19 8:12 PM, Hiroshi Yamauchi wrote: > Here's a revised approach based on the discussion: > > - Cache PSI right after the profile summary 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

On Thu, Dec 10, 2015 at 4:00 PM, Philip Reames <listmail at philipreames.com> wrote: > Given I didn't get any response to my original query, I chose not to invest > time in this at the time. I am unlikely to get time for this in the near > future. > > On 12/07/2015 03:13 PM, Easwaran Raman wrote: > > (Resending after removing llvmdev at cs.uiuc.edu and using >

On 3/14/19 2:04 AM, Hiroshi Yamauchi wrote: > > > On Wed, Mar 13, 2019 at 2:37 PM Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > >> >> - Add a new proxy ModuleAnalysisManagerLoopProxy for a loop pass >> to be able to get to the ModuleAnalysisManager in one step and >> PSI through it. >

> On 2015-Jun-04, at 12:45, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-Jun-04, at 12:28, Ivan Baev <ibaev at codeaurora.org> wrote: >> >> Hi, we got the following assert: >> >> assert(!Working[0].isLoopHeader() && "entry block is a loop header"); >> >> [in

Hi, we got the following assert: assert(!Working[0].isLoopHeader() && "entry block is a loop header"); [in BlockFrequencyInfoImpl<BT>::tryToComputeMassInFunction(), BlockFrequencyInfoImpl.h] on a Hexagon target - the entry block is a loop header. Has someone seen this assert on other targets? What would be a preferable way to fix it: - extend BlockFrequency pass to

Hey, I am trying to use the BlockFrequencyInfoWrapperPass to obtain hotness information in my LLVM pass. Attached is a minimal example of code which creates a SIGSEGV. The pass calls AU.addRequired<BlockFrequencyInfoWrapperPass>(); in getAnalysisUsage(..). The problem exists with changed and unchanged IR. The binary is instrumented like this: clang input.bc -fprofile-generate -o

Functions in LLVM IR have a function_entry_count metadata that is attached in PGO compilation. By using the entry count together with the block frequency info, the compiler computes the profile count of call instructions based on which the hotness/coldness of callsites can be determined. Experiments have shown that using a higher threshold for hot callsites results in improved runtime performance

Good evening, guys! At first, I apologize my report is a little gross, I have so little time to do checking process minutely. * RC1 RC1 can be built on VS8, 9, 10 with Debug|Release. At one point, r127264(in release_29/trunk) is needed to build with Debug on VS10. RC1 can pass clang-test with any configurations. RC1 fails llvm's check on many tests. * RC1 and patches ToT would be ready

Hi Alok, On 16/07/12 12:41, #ALOK PRAKASH# wrote: > I have been using the Profile.pl and the related passes and > optimizations for about 4 years now. With every new release lately, the > support for the profile scripts and their framework seemed to be > downgrading. Hence, I used my own tiny one line fixes to keep them > working. I offered to send these small patches to keep these

I will be out of the office starting 21.04.2005 and will not return until 25.04.2005. I will respond to your message when I return. In urgent cases please contact Mr. Michael Klein (michael.klein@bnpparibas.com) +49(0)6971936960. With kind regards, Eric Moos This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive

I will be out of the office starting 09.03.2005 and will not return until 14.03.2005. I will respond to your message when I return. In urgent cases please contact Mr. Michael Klein (michael.klein@bnpparibas.com) +49(0)6971936960. With kind regards, Eric Moos This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive

I will be out of the office starting 25.05.2005 and will not return until 26.05.2005. I will respond to your message when I return. In urgent cases please contact Mr. Michael Klein (michael.klein@bnpparibas.com) +49(0)6971936960. With kind regards, Eric Moos This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive

Hello everyone At EuroLLVM I presented some testing work we have been doing on improving correctness of the MC Layer for ARM. There seemed to be interest from the community in seeing the results of this test suite. Background ----------- We are using a test suite, called MC Hammer, that compares MC with an ARM in-house implementation of the same functionality. The test space for this suite is

I would like to start prototyping changes towards profile guided inlining. Before doing so, I wanted to get feedback from the community on the appropriate approach. I'm going to layout a strawman proposal, but I'm open to other ideas on how to approach the problem. Depending on what approach we settle on, I *may* be able to commit resources to actually implement this in the near