[llvm-commits] Static Profile Patch
Dan Gohman
gohman at apple.com
Mon Sep 14 08:54:19 PDT 2009
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
More information about the llvm-commits
mailing list