search for: getedgeprob

...ass >();* >> Now, I have the following queries. >> >> - How do I use the edge count and branch weights data obtained using >> PGOInstrumentationUse in my pass and replace the *getEdgeWeight()* >> from ProfileInfo? >> >> > You can do > BPI.getEdgeProbability(Src, Dest).scale(BFI.getBlockProfileCount(Src)); > I tried doing this but there are some semantic issues that I'm facing. There is a loop in my program which I know is a hot loop since it is the only loop inside the function main() and essentially, all the computations are performed...

...unction::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 strong opinions abou...

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

...;>> >>>> - How do I use the edge count and branch weights data obtained >>>> using PGOInstrumentationUse in my pass and replace the >>>> *getEdgeWeight()* from ProfileInfo? >>>> >>>> >>> You can do >>> BPI.getEdgeProbability(Src, Dest).scale(BFI.getBlockProfileCount(Src)); >>> >> >> I tried doing this but there are some semantic issues that I'm facing. >> There is a loop in my program which I know is a hot loop since it is the >> only loop inside the function main() and essen...

...> - 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 anyway by adding a...

...lated the sum of the weights as 24+16+24+16+16 = 96. In LLVM 3.2 getSumForBlock was changed to use getEdgeWeight(MBB*, MBB::succ_iterator), causing it to calculate the sum of weights now correctly as 24+16+16+16+16 = 88. However, in include/llvm/Analysis/BlockFrequencyImpl.h:202 doBlock() uses getEdgeProbability(MBB*, MBB*) when iterating over the ingoing edges of the default block, which only returns the probability for the first edge twice. Due to this and the now correct result of getSumForBlock, the sum of the probabilities of the outgoing edges of the switch block is now greater than 1, and...

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

...ch(*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 you could use the...

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