search for: mbpi

...+MachineFunction::iterator(From); Does C++ allow this these days? I would prefer llvm::next(MachineFunction::iterator(From)) Note that MachineFunction::iterator decays into an MBB pointer, so you can say FI->canFallThrough() and AnalyzeBranch(*FI...) + WeightedEdge WE = { BaseFrequency * MBPI->getEdgeProbability(From, To), Did we add API for this computation? We intended to add a function that computes this and saturates on overflow etc. > Still, for the test cases that don't tickle the iteration bug, it generates beautiful, well laid out code. =] I am sure others have stro...

...n class. > - Use a separate anonymous namespace per class, and don't indent for the namespace. > ... > Note that MachineFunction::iterator decays into an MBB pointer, so you can say FI->canFallThrough() and AnalyzeBranch(*FI...) > > + WeightedEdge WE = { BaseFrequency * MBPI->getEdgeProbability(From, 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 any...

...EntryCount > 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, like "hasRe...

...uot;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...

Dear Duncan, I am generating branch-weights annotated IR files as described in the documentation of LLVM, using profiling with instrumentation. http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation e.g. llvm-profdata merge -output=$(BENCH).profdata default.profraw > clang -S -emit-llvm -O3 -fprofile-instr-use=$(BENCH).profdata -o > bench.prof.ll bench.c The issue is

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 >

On Wed, Oct 19, 2011 at 3:24 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Oct 18, 2011 at 6:58 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > >> >> On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: >> >> As for why it should be an IR pass, mostly because once the selection >>> dag runs through the code, we can never

...alyzeBranch(*FI...) > I'm aware, but there were a few weird places where it didn't happen, and 'From' seemed like a more readable name anyways... Lemme know if you'd really rather I use the iterator everywhere. > > > > + WeightedEdge WE = { BaseFrequency * MBPI->getEdgeProbability(From, > 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 y...

On Tue, Oct 18, 2011 at 6:58 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: > > As for why it should be an IR pass, mostly because once the selection dag >> runs through the code, we can never recover all of the freedom we have at >> the IR level. To start with, splicing MBBs around requires known about