search for: blockfrequencies

[Splitting this out from the original thread to reduce noise in it] On 17.06.2013, at 18:43, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 17, 2013, at 7:03 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > >> >> On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: >> >>> On 2013-06-15 16:39 ,

The BlockFrequency analysis has been useful for machine block placement, register allocation and other function-level optimizations. How could we extend it for use in an inter-procedural (whole-program) context? For example, if we would like to compare the hotness of two call sites in different functions, or calculate the hotness of two global variables referenced in multiple functions. If the

On Jun 17, 2013, at 10:48 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > [Splitting this out from the original thread to reduce noise in it] > > > On 17.06.2013, at 18:43, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> +LiveIntervals::getSpillWeight(bool isDef, bool isUse, BlockFrequency freq) { >> + return (isDef + isUse) * freq.getFrequency();

David Is this true for static heuristics as well ? If the bb freqs are scaled wrt to the entry block freq and a) use such scaled freqs for the bb's that have calls b) propagate this info topologically over the call graph, how representative will be the info if one just wants to use in a comparative sense ? -Dibyendu Sent from my Windows Phone ________________________________ From: Xinliang

On Jun 17, 2013, at 7:03 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > > On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: > >> On 2013-06-15 16:39 , Benjamin Kramer wrote: >>> Do you want to take over this effort or should I poke more at it? >> >> Since you've already started, it's easier if you poke more at

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 all, I have a piece of code (written in LLVM 2.8) which uses profiling results produced by ProfileInfo. It essentially computes the number of iterations performed by a loop from the profiling information available. The code snippet in my pass looks something like this. BasicBlock *header = loop->getHeader(); ProfileInfo &pi = getAnalysis< ProfileInfo >(); for(pred_iterator

On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: > On 2013-06-15 16:39 , Benjamin Kramer wrote: >> Do you want to take over this effort or should I poke more at it? > > Since you've already started, it's easier if you poke more at it. Thanks. I've got a whole bunch of other things to go through. OK, will do. Jakob any comments on the

Thank you so much for your response. On Wed, Aug 15, 2018 at 3:08 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > > > On Wed, Aug 15, 2018 at 7:36 AM Malhar Thakkar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hey all, >> >> I have a piece of code (written in LLVM 2.8) which uses profiling results >> produced by ProfileInfo.

On Feb 2, 2014, at 6:18 PM, Andrew Trick <atrick at apple.com> wrote: >> The result of such a system would produce weights for every block in the above CFG as '1.0', or equivalent to the entry block weight. This to me is a really useful metric -- it indicates that no block in the CFG is really more or less likely than any other. Only *biases* in a specific direction would

On Wed, Aug 15, 2018 at 1:28 PM Xinliang David Li <xinliangli at gmail.com> wrote: > > > On Wed, Aug 15, 2018 at 12:46 PM Malhar Thakkar <cs13b1031 at iith.ac.in> > wrote: > >> Thank you so much for your response. >> >> On Wed, Aug 15, 2018 at 3:08 PM, Xinliang David Li <xinliangli at gmail.com> >> wrote: >> >>> >>>

On Mon, Jun 17, 2013 at 11:03 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > >> This computation can overflow. > > > > Yep, I went down the easy route and converted it to floating point > arithmetic. Is that OK here? > > Yes, that should be fine. I really don't think this is fine. I would like for LLVM to not rely on floating point arithmetic on

> 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

Hello folks, I'd like to remove all of the old and defunct profile info passes from LLVM. These have been almost entirely supplanted by the BranchProbability and BlockFrequency systems, which are actually on by default, and in use in optimization passes. The old system is not on, and hasn't been touched in years except to do minor build fixes and updates. As far as I'm aware, the

Hi Chandler, I'm a GSoC student working on profiling support (mentor CC'ed). I'm no stranger to the issues with the current system: my original proposal was written without knowledge of the limitations. This is why this list hasn't heard much from me yet. I would like to continue working on profiling support but I'm not attached to ProfileInfo and wouldn't be

I’d like to nominate code owners for: PGO (CodeGenPGO, ProfileData, llvm.instprof): Justin Bogner Branch Weights and BlockFrequency: Duncan Smith -Andy

...useful for is establishing a total ordering over the basic blocks of a function. So it works well for some things like code layout, but is grossly misleading for others. There are several possible solutions here. I'll outline my proposal as well as some other ideas. BlockWeights instead of BlockFrequencies. My idea is that we don't really care about the depth of the control dependence for a particular basic block. We care about the accumulated *bias* toward or away from a basic block. This is predicated on the idea that branches are overwhelmingly predictable. As a consequence, evenly distributed...

On Sun, Jul 15, 2012 at 8:32 AM, Alastair Murray <alastairmurray42 at gmail.com > wrote: > Hi Chandler, > > I'm a GSoC student working on profiling support (mentor CC'ed). I'm no > stranger to the issues with the current system: my original proposal was > written without knowledge of the limitations. This is why this list > hasn't heard much from me yet.

TLDR - The proposal below is intended to allow inlining of larger callees when such inlining is expected to reduce the dynamic instructions count. Proposal ------------- LLVM inlines a function if the size growth (in the given context) is less than a threshold. The threshold is increased based on certain characteristics of the called function (inline keyword and the fraction of vector

On 01/07/2015 05:33 PM, Chandler Carruth wrote: > > On Wed, Jan 7, 2015 at 5:19 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > I've been playing with approaches to getting better optimization > of loops which contain infrequently executed slow paths. I've > gotten as far as throwing together