search for: branchprob

...ev/zero is needed for mmap... no configure: WARNING: mmap() of a fixed address required but not supported checking for GCC atomic builtins... yes With this warning, I run the following make script PATH=/bin:/usr/bin make CXXFLAGS=-std=c++0x and I get the following build error. llvm[1]: Compiling BranchProbability.cpp for Release+Asserts build In file included from /cygdrive/c/OpenSource/llvm-3-3/lib/Support/BranchProbability.cpp:16:0: /cygdrive/c/OpenSource/llvm-3-3/include/llvm/Support/Format.h: In member function ‘int llvm::format_object1<T>::snprint(char*, unsigned int) const [with T = doubl...

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

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

...red_iterator i=pred_begin(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 prof...

...on profiling support beyond 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 fo...

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

..., and we don't want to expose edge weights, because they have no independent meaning, we need a richer API. Example: BasicBlock *getHotSucc(BasicBlock *BB); bool isEdgeHot(BasicBlock *pred, BasicBlock *succ); The API will be implemented entirely using fixed point arithmetic. Example: class BranchProbability { friend BranchProbabilityInfo; unsigned numerator; unsigned denominator; BranchProbability(...); // no public ctor ... }; class BranchProbabilityInfo { static BranchProbability HotProb; static initProb(); ... }; void BranchProbabilityInfo::initProb() { HotProb = Branch...

...issues with the current system: 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 resp...

...ed two debugging lines that print floating-point numbers for the sake of demonstration that such printing works fine. >> >> bool MeetIfcvtSizeLimit(MachineBasicBlock &BB, >> unsigned Cycle, unsigned Extra, >> const BranchProbability &Prediction) const { >> >> dbgs() << "OOPS " << 1.14 << "\n"; >> bool flag = Cycle > 0 && TII->isProfitableToIfCvt(BB, Cycle, Extra, >>...

...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 have? Once I have a Block...

I'm look at some code that does something roughly like this if (a >= 10 && a < 20) { // do calculation } else if (a >= 30 && a < 40) { // do calculation } else if (a >= 50 && a < 60) { // do something } else if (a >= 70 && a < 80) { // do something } // some other code that got split based on whether we entered any of the

...rint > floating-point numbers for the sake of demonstration that such printing > works fine. > >> > >> bool MeetIfcvtSizeLimit(MachineBasicBlock &BB, > >> unsigned Cycle, unsigned Extra, > >> const BranchProbability &Prediction) const { > >> > >> dbgs() << "OOPS " << 1.14 << "\n"; > >> bool flag = Cycle > 0 && TII->isProfitableToIfCvt(BB, > Cycle, Extra, > >>...

...stranger to the issues with the current system: 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 resp...

I tried to build the stable LLVM 3.2, and the latest from svn. Both failed, unfortunately. During compilation process, I saw this: llvm[1]: Compiling BranchProbability.cpp for Release build 0 clang 0x00000000010b23bf 1 clang 0x00000000010b2a0d 2 libpthread.so.0 0x00002b3c53ed2ff0 3 clang 0x00000000005f7200 4 clang 0x0000000000627c05 5 clang 0x000000000074c567 6 clang 0x000000000074bf35 7 c...

...(): In the IfConverter, I have added two debugging lines that print floating-point numbers for the sake of demonstration that such printing works fine. bool MeetIfcvtSizeLimit(MachineBasicBlock &BB, unsigned Cycle, unsigned Extra, const BranchProbability &Prediction) const { dbgs() << "OOPS " << 1.14 << "\n"; bool flag = Cycle > 0 && TII->isProfitableToIfCvt(BB, Cycle, Extra, Prediction);...

...nes that print floating-point numbers for the sake of demonstration that such printing works fine. > >> > >> bool MeetIfcvtSizeLimit(MachineBasicBlock &BB, > >> unsigned Cycle, unsigned Extra, > >> const BranchProbability &Prediction) const { > >> > >> dbgs() << "OOPS " << 1.14 << "\n"; > >> bool flag = Cycle > 0 && TII->isProfitableToIfCvt(BB, Cycle, Extra, > >>...

Recently I was looking into porting IRCE loop pass into the new pass manager and stumbled on a problem. The problem is due to the existing hard dependency of IRCE on BranchProbability analysis. If I understand it right, in a new pass manager there are only two ways for loop analysis to ask for the result of an "outer" (function/module-level) analysis:   - get it from a predefined LoopStandardAnalysisResults set     BPI is not there, so it unsuitable for me r...

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

...tadata by profiling At the absolute minimum this will require writing a new profile loader which will set branch weight metadata based on profiling data. #1 Optionally use profiling support to heuristics within: * Loop unrolling * Loop unswitching * Inliner The existing BranchProbabilityInfo, and BlockFrequencyInfo are not used in Transforms/*/* at all, just in CodeGen/*. Is there a reason for this, or is it quite possible to use them in Transforms/*/* passes? The original plan was to test these using ProfileEstimator, now the static heuristics within BranchProbability...

...oning was that a) this is a 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). > If so, is the notion of 'rareness' of a loop block something that's worth extracting out on it's own and reusing? Are there other similar uses an...