search for: blockfrequ

...e more at it. Thanks. I've got a whole bunch of other things to go through. >> >> OK, will do. >> >> >> Jakob any comments on the patch? The only interesting part is in LiveIntervals::getSpillWeight. Do we have to scale the values somehow there? > > Yes, BlockFrequency::getFrequency() is poorly named, it returns a fixpoint number. I think you should scale it to be relative to the entry block frequency. > > +LiveIntervals::getSpillWeight(bool isDef, bool isUse, BlockFrequency freq) { > + return (isDef + isUse) * freq.getFrequency(); > } > &gt...

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

...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(); >> } >> >> 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. +LiveIntervals::getSpillWeight(bo...

...Sent from my Windows Phone ________________________________ From: Xinliang David Li<mailto:xinliangli at gmail.com> Sent: ‎12/‎27/‎2014 10:05 AM To: ibaev at codeaurora.org<mailto:ibaev at codeaurora.org> Cc: llvmdev<mailto:llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] How to use BlockFrequency in inter-procedural context? On Fri, Dec 26, 2014 at 7:12 PM, <ibaev at codeaurora.org<mailto:ibaev at codeaurora.org>> wrote: The BlockFrequency analysis has been useful for machine block placement, register allocation and other function-level optimizations. How could we extend i...

...ed, 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 patch? The only interesting part is in LiveIntervals::getSpillWeight. Do we have to scale the values somehow there? Yes, BlockFrequency::getFrequency() is poorly named, it returns a fixpoint number. I think you should scale it to be relative to the entry block frequency. +LiveIntervals::getSpillWeight(bool isDef, bool isUse, BlockFrequency freq) { + return (isDef + isUse) * freq.getFrequency(); } This computation can overfl...

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 handle this case, e.g. by inserting a dumm...

...gin(header), e=pred_end(header); i!=e; ++i) { BasicBlock *pred = *i; const double edgeCount = *pi.getEdgeWeight*( ProfileInfo::Edge(pred,header) ); */* Some code */* } Now, since ProfileInfo has been deprecated and we have PGOInstrumentation passes along with BranchProbability and BlockFrequency, I wish to update the above snippet, in particular, obtaining the edge weights (highlighted in the code above) using the new tools. In order to do that, I'm first generating edge count profile by the PGOInstrumentationGen pass and then interpreting the edge count profile with PGOInstrument...

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

...k *pred = *i; >> >> const double edgeCount = *pi.getEdgeWeight*( ProfileInfo::Edge(pred,header) ); >> */* Some code */* >> } >> >> Now, since ProfileInfo has been deprecated and we have PGOInstrumentation >> passes along with BranchProbability and BlockFrequency, I wish to update >> the above snippet, in particular, obtaining the edge weights (highlighted >> in the code above) using the new tools. >> >> In order to do that, I'm first generating edge count profile by the >> PGOInstrumentationGen pass and then interpreti...

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

...t double edgeCount = *pi.getEdgeWeight*( ProfileInfo::Edge(pred,header) ); >>>> */* Some code */* >>>> } >>>> >>>> Now, since ProfileInfo has been deprecated and we have >>>> PGOInstrumentation passes along with BranchProbability and BlockFrequency, >>>> I wish to update the above snippet, in particular, obtaining the edge >>>> weights (highlighted in the code above) using the new tools. >>>> >>>> In order to do that, I'm first generating edge count profile by the >>>> PGOIns...

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

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

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 only thing the old system supported which the new one does not is loading profi...

...eyond the end date, long-term (though not full time). I do compiler research, but not currently with LLVM -- so this is a genuine desire and plan. Perhaps the best way to proceed is to remove ProfileInfo etc and then I can work on re-adding/re-writing it with support for BranchProbability and BlockFrequency. Then I can maintain what I add. (As an unknown figure offering to maintain the existing code seems a bit hollow.) Naturally, any changes to my GSoC plans need discussion with my mentor. A few specifics below. On 15/07/12 20:07, Chandler Carruth wrote: > Hello folks, > > I'd...

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

...: local and relative branch probabilities. These merely express the likelihood of taking one of a mutually exclusive set of exit paths from a basic block. They are very simple, and the foundation of the profile information. Even the other analysis is merely built on top of this one. Second we have BlockFrequencyInfo which attempts to provide a more "global" (function-wide, not actually program wide) view of the statistical frequency with which any particular basic block is executed. This is nicely principled analysis that just computes the probabilistic flow of control through the various bra...

...ystem: my original proposal was > written without knowledge of the limitations. This is why this list > hasn't heard much from me yet. > It would be better to actually email the list with the problems you are hitting sooner. We would have directed you to the BranchProbabilityInfo and BlockFrequencyInfo infrastructure that is now actively in use by several optimization passes in LLVM. Can you start a thread with what your specific goals are? The only email I have from you is from May 1st, which was your project outline for the GSoC application, to which Evan responded, but to which nothin...

...at controls threshold. This would allow larger functions whose inlining potentially reduces execution time to be inlined. The dynamic instruction count of (an uninlined) function F is DI(F) = Sum_BB(Freq(BB) * InstructionCount(BB)) * The above summation is over all basic blocks in F. * Freq(BB) = BlockFrequency(BB)/BlockFrequency(Entry(F)) This dynamic instruction count measurement doesn't distinguish between a single-cycle instruction and a long latency instruction. Instead of using InstructionCount(BB)), we could use Sum_I(Weight(I)) where the summation is over all instructions I in B and Weigh...

...rarely taken case and adding an expensive analysis dependency > probably wasn't worthwhile and b) that block frequency > analysis was more expensive/precise than I really needed. Is > this reasonable? > > I think we should always use the analyses. Either BlockFrequency or > BranchProbability. I think probably both in the common joint usage > (frequency of the loop header combined with probability of the cold > region). Let me ask a basic question: what do BlockFrequency and BranchProbability compute and roughly what mental cost model should I ha...