[llvm-commits] Static Profile Patch

[Dan Gohman]

Hi Andrei,

Here are some review comments for this patch.  I think it would be
fine to check into the tree at this point, so that future changes can
be reviewed incrementally instead of with monolithic patches.

BranchPredictionPass has
     double getEdgeProbability(Edge &edge) const;
as a public member function, but Edge is a private typedef, so one of
these has the wrong visibility.

The passes should override the Pass::releaseMemory virtual function.
Some currently have a Clear member function; they should implement
releaseMemory and have it call Clear, or perhaps Clear should be
renamed releaseMemory, depending on how it's used.

lib/Analysis/BranchPredictionPass.cpp has
#include "llvm/Transforms/Utils/BasicBlockUtils.h"
which is a red flag because lib/Analysis code is not allowed to
depend on lib/Transforms code. However, this #include appears to be
unneeded, so it should be removed.

BranchHeuristicsInfo::MatchCallHeuristic and some of the others
don't test whether the terminator is a BranchInst. It looks like
there's nothing preventing them from analyzing a block with an
InvokeInst as its terminator. Is that intended by the heuristics?
BranchHeuristicsInfo::postDominates calls
PostDominatorTree::properlyDominates. Since the distinction between
domination and proper domination is often both subtle and critical
for algorithm correctness, please either rename this function or add
comments or both.

BranchPredictionInfo::FindBackEdges does a DominatorTree query for
every edge in the function. It would be possible to get a close
approximation of this using LoopInfo. That would miss unnatural
loops and spaghetti code though; is that the reason for doing the
full traversal? Please add a comment about this.

BranchPredictionInfo::FindExitEdges seems to be redundant with
Loop::getExitEdges.

Could BranchPredictionInfo::FindStores and FindCalls be combined
to avoid doing so many function traversals?

In its current form, BranchPredictionPass won't be usable in LLVM's
default optimization pipeline because it requires post-dominator tree
construction. None of LLVM's current default optimization passes
require post-dominator trees, so constructing it just for this pass
will likely be too slow. It could possibly be justified for -O3,
if there are sufficient benefits to oughtweigh the costs. There are
many LLVM users that don't use the standard -O2 or -O3 passes
also, of course.

Dan

On Sep 11, 2009, at 6:46 PM, Andrei Alvares wrote:

> Hello everyone,
>   Since this patch hasn't been applied yet, I'm taking the liberty  
> to send a more updated version. I made several changes in the branch  
> predictor (BranchPredictionPass) and in the intra procedural static  
> profiler (BlockEdgeFrequencyPass).
>   Attachment: stprof-11.09.09.patch.
>
>   While I was debbuging the code, I've noticed that I was  
> maintaining data across multiple calls of runOnFunction on both  
> passes, which was indeed an undesirable behavior. After cleaning up,  
> both passes shown improved results. In fact, the branch predictor  
> produced very close related prediction as Ball's predictor. I ran  
> the branch predictor on the SPEC 2000 (int and float). I'm attaching  
> "heuristics.txt" which compared results separated by heuristic for  
> both predictors. While most heuristics predicted more accurately,  
> the call and opcode heuristics shown worst results. This means that  
> is still space for improvements. Also, I've found a bug in the way  
> the predictor threats a branch that have some backedge sucessors,  
> but not all. I expected that the other branches were always exit  
> edges, but there are cases that this situation is not true.
>
>   Moreover, while calculating blocks and edge frequencies it is  
> possible to verify if it is calculating correct frequency  
> information. Since the entry block frequency is always one, is  
> expected that the exit's total frequency is also one. So, all we  
> need to do is check the sum of all predecessors edges of exit's  
> basic blocks to match one. However, I've found two cases of  
> miscalculation by the pass: (1) when the control flow graph is not  
> reducible; (2) when seems to be a loop that does not terminates (has  
> no exit blocks). Although this pass can calculate frequencies for  
> those situations, it might not be accurate. Nevertheless, seems like  
> the pass is doing what is supposed to.
>
>   The global static profiler (inter procedural) is not as accurate  
> as Wu's paper yet. But after those fixes, it has improved quite  
> significantly. I'm attaching the results of the profiler comparing  
> the correct prediction rate of the top most executed blocks, edges,  
> and function call invocations (ranging from 10% to 50%).  
> Attachments: block.txt, edge.txt and call.txt.
>
>   Thanks,
>     Andrei
>
> On Wed, Sep 2, 2009 at 3:37 PM, Andrei Alvares <logytech at gmail.com>  
> wrote:
> Hello everyone,
>  Here it follows the static profiler implementation, developed as
> part of my google summer of code project. It performs branch
> predictions in compilation time, i.e., assign probabilities to branch
> outcomes using a set of predefined heuristics. Also, it calculates
> intra and interprocedural profiling by staticly estimate basic blocks
> and edges frequencies (local and global) and function call invocations
> frequencies.
>  Attachment: stprof-02.02.09.patch
>
>  I've run the static profiler on some of the SPECint 2000 programs
> (those that I was able to compile and run).  It has not yet achieved
> the accuracy found in Wu's paper, but I believe it can still be
> improved.
>  Best regards,
>    Andrei
>
> Youfeng Wu and James R. Larus. Static branch frequency and program
> profile analysis. In MICRO 27: Proceedings of the 27th annual
> international symposium on Microarchitecture. IEEE, 1994.
>
> < 
> heuristics 
> .txt 
> > 
> < 
> blocks 
> .txt 
> > 
> < 
> edge 
> .txt 
> > 
> < 
> call 
> .txt 
> > 
> <stprof-11.09.09.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits