search for: machineblockfrequencyinfo

...return (isDef + isUse) * freq.getFrequency(); } 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 = +...

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

...ed it to floating point arithmetic. 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)); > +...

...r others to find in the > archive. If you have any follow-up questions, please add llvm-dev > to the CC list.) > > Assuming you already have branch weights, you should use the > BlockFrequencyInfo analysis to calculate the block frequencies. At > the Machine level, there's a MachineBlockFrequencyInfo analysis. > > The frequencies shouldn't be used in isolation, but with reference > to each other. > > Cheers, > Duncan > > > On 2016-Feb-03, at 00:43, Giorgio Zacharo <giorgiozacharo at gmail.com> > wrote: > > > > Dear Duncan, > > > >...

...o you have any concerns about the feasibility this approach? As to step 1, I haven't dug too deeply into the problem yet, but I'm starting from the assumption that we'll be moving only the modules that start with 'Machine' into the new library. These are: - MachineBasicBlock - MachineBlockFrequencyInfo - MachineBlockPlacement - MachineBranchProbabilityInfo - MachineCodeEmitter - MachineCopyPropagation - MachineCSE - MachineDominators - MachineFunctionAnalysis - MachineFunction - MachineFunctionPass - MachineFunctionPrinterPass - MachineInstrBundle - MachineInstr - MachineLICM - MachineLoopInfo -...

...gt; archive. If you have any follow-up questions, please add llvm-dev > > to the CC list.) > > > > Assuming you already have branch weights, you should use the > > BlockFrequencyInfo analysis to calculate the block frequencies. At > > the Machine level, there's a MachineBlockFrequencyInfo analysis. > > > > The frequencies shouldn't be used in isolation, but with reference > > to each other. > > > > Cheers, > > Duncan > > > > > On 2016-Feb-03, at 00:43, Giorgio Zacharo <giorgiozacharo at gmail.com> > wrote: > > &gt...

...om, To), > > Did we add API for this computation? We intended to add a function that computes this and saturates on overflow etc. Overflow is handled transparently in the overloaded BlockFrequency::operator*(BranchProbability). But you could use the existing API anyway by adding a helper to MachineBlockFrequencyInfo calling BlockFrequencyImpl::getEdgeFreq(Src,Dst). >> Still, for the test cases that don't tickle the iteration bug, it generates beautiful, well laid out code. =] > > I am sure others have strong opinions about the algorithm ;-) I may be one of those others ;-). Although handling...

Hi, I've been trying to get frequency information for basic blocks and edges between basic blocks using MachineBlockFrequencyInfo and MachineBranchProbabilityInfo. Unfortunately, the results returned don't seem to give high consistency. If I have code like the following: define i32 @foo(i32 %i, i32* %addr) { entry: %tobool = icmp ne i32 %i, 0 br i1 %tobool, label %if.end, label %if.then if.then: %add = add i...

On Wed, Jun 12, 2013 at 2:55 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > That sounds plausible to me. It seems like we might need a way of > representing call graph profiling in addition to the existing branch > probabilities? > Agreed. An important consideration here is WPO vs. LTO vs. TU-at-a-time call graphs. > FWIW, the greedy register allocator’s live range

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

...easibility this approach? > > As to step 1, I haven't dug too deeply into the problem yet, but I'm > starting from the assumption that we'll be moving only the modules > that start with 'Machine' into the new library. These are: > > - MachineBasicBlock > - MachineBlockFrequencyInfo > - MachineBlockPlacement > - MachineBranchProbabilityInfo > - MachineCodeEmitter > - MachineCopyPropagation > - MachineCSE > - MachineDominators > - MachineFunctionAnalysis > - MachineFunction > - MachineFunctionPass > - MachineFunctionPrinterPass > - MachineInstrB...

On Oct 19, 2011, at 5:50 AM, Chandler Carruth wrote: > Ok, wow that wasn't hard at all. Awesome ;-) > This is still *very* much a rough draft, but it's probably better to review that the previous patch. One big caveat, I know I have an iteration bug in here somewhere that is inf-looping. Just ran out of steam debugging it, will pick it back up again later today to shake it out.

Hi Quentin, Thanks for the reply! However, we are not using any profiling-based compilation in our current work. We are assuming that, if PGO is disabled, the register allocator (and any other pass that needs basic block frequency info) will be basing its decisions on some kind of *static" basic block frequency info that are based on some compile-time heuristics and at least capture loop

I'm trying to compute and print a weighted spill cost 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()

...we add API for this computation? We intended to add a function that > computes this and saturates on overflow etc. > > Overflow is handled transparently in the overloaded > BlockFrequency::operator*(BranchProbability). But you could use the existing > API anyway by adding a helper to MachineBlockFrequencyInfo calling > BlockFrequencyImpl::getEdgeFreq(Src,Dst). > Yea, this should be handled by the BlockFrequency object correctly here, but if you'd rather see the helper I can add that. Was just keeping this patch more focused on the pass. > >> Still, for the test cases that don't...

...Release+Asserts Archive Library libLLVMLineEditor.a make[2]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/LineEditor' llvm[2]: Compiling MCMachObjectTargetWriter.cpp for Release+Asserts build llvm[3]: Compiling PDBSymbolCompilandEnv.cpp for Release+Asserts build llvm[2]: Compiling MachineBlockFrequencyInfo.cpp for Release+Asserts build llvm[2]: Compiling MCNullStreamer.cpp for Release+Asserts build llvm[3]: Compiling PDBSymbolCustom.cpp for Release+Asserts build llvm[3]: Compiling PDBSymbolData.cpp for Release+Asserts build llvm[2]: Compiling MCObjectFileInfo.cpp for Release+Asserts build llvm[3]: Co...