search for: mbfi

...etFrequency(); } This computation can overflow. @@ -178,9 +180,10 @@ bool SpillPlacement::runOnMachineFunction(MachineFunction &mf) { // Compute total ingoing and outgoing block frequencies for all bundles. BlockFrequency.resize(mf.getNumBlockIDs()); + MachineBlockFrequencyInfo &MBFI = getAnalysis<MachineBlockFrequencyInfo>(); for (MachineFunction::iterator I = mf.begin(), E = mf.end(); I != E; ++I) { - float Freq = LiveIntervals::getSpillWeight(true, false, - loops->getLoopDepth(I)); + float Freq = + LiveIn...

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

...ost based upon the execution frequency of the basic block where the spill is inserted. My goal is to analyse what effect scheduling changes have on the sum of this weighted spill cost in some benchmarks. I've experimented doing this directly before a spill is inserted in InlineSpiller.cpp using MBFI.getBlockFreq() and LiveIntervals::getSpillWeight. My question is why are these functions sometimes indicating that the frequency of a block, or the weight of a spill is 0? A frequency of 0 doesn't make sense to me. Thanks, Austin Kerbow

...tic. Is that OK here? > > @@ -178,9 +180,10 @@ bool SpillPlacement::runOnMachineFunction(MachineFunction &mf) { > > // Compute total ingoing and outgoing block frequencies for all bundles. > BlockFrequency.resize(mf.getNumBlockIDs()); > + MachineBlockFrequencyInfo &MBFI = getAnalysis<MachineBlockFrequencyInfo>(); > for (MachineFunction::iterator I = mf.begin(), E = mf.end(); I != E; ++I) { > - float Freq = LiveIntervals::getSpillWeight(true, false, > - loops->getLoopDepth(I)); > + float Fre...

...ost based upon the execution frequency of the basic block where the spill is inserted. My goal is to analyse what effect scheduling changes have on the sum of this weighted spill cost in some benchmarks. I've experimented doing this directly before a spill is inserted in InlineSpiller.cpp using MBFI.getBlockFreq() and LiveIntervals::getSpillWeight. My question is why are these functions sometimes indicating that the frequency of a block, or the weight of a spill is 0? A frequency of 0 doesn't make sense to me. I don’t know how PGO is implemented in that respect so take it with a grain of...

Hello, I have worked on LLVM for my project related to Register Allocation. Bernhard Scholz suggested that Implementing Branch and Bound Heuristic for Reduce N in PBQP register Allocation for LLVM would be to great project to work on. I'm looking forward to implement it in LLVM system. How should i get start about it ? I would also like to know about some of the other projects in LLVM.

In include/llvm/ADT/Statistic.h, the identifier “DEBUG_TYPE” is never defined. I’ve noticed it’s defined as different things in a few other header files, including llvm/Analysis/BlockFrequencyInfoImpl.h, llvm/Analysis/RegionInfoImpl.h, llvm/Support/UnicodeCharRanges.h, llvm/Transforms/InstCombine/InstCombineWorkList.h, and llvm/Transforms/Utils/SSAUpdaterImpl.h. Should I edit Statistic.h so that

...reference getEntryCount > are using it to check "HasProfileData". So adding synthetic values would > cause us to take a lot of code paths in the compiler that were intended to > use real profile data. > > As a simple example, MachineBlockPlacement::collectLoopBlockSet uses MBFI > and MBPI guarded by a check of getEntryCount to see if PGO data is present > (the comment even says "This needs precise profile data and we only do this > when profile data is available."). Do we need to refactor things first to > use a more semantically meaningful check, li...

...check "HasProfileData". So adding synthetic values would >>> cause us to take a lot of code paths in the compiler that were intended to >>> use real profile data. >>> >>> As a simple example, MachineBlockPlacement::collectLoopBlockSet uses >>> MBFI and MBPI guarded by a check of getEntryCount to see if PGO data is >>> present (the comment even says "This needs precise profile data and we only >>> do this when profile data is available."). Do we need to refactor things >>> first to use a more semantically m...

On Fri, Dec 15, 2017 at 12:22 AM, Sean Silva <chisophugis at gmail.com> wrote: > IIUC, this proposal is just saying that we should infer a static profile > for entry counts just like we do for branch probabilities. In the case of > entry counts, we do not hide that information behind an analysis like BPI, > so currently just annotating synthetic PGO entry counts is a simple >