[PATCH] [MemoryDependenceAnalysis] Fix compile time slowdown
dberlin at dberlin.org
Tue Sep 30 11:04:59 PDT 2014
FWIW: THis looks reasonable to me.
If you can give me the program, i'd love it.
I have been working on some patches to dramatically speed up memdep for
gvn's use case:
Two possible approaches
1. by using quadtrees to store and lookup the nearest affecting
loads/stores for a given load/store
2. by using quadtrees to store and lookup the nearest loads/stores to a
given bb. A lot of memdep time is spent doing the walks, not the dependence
Quadtrees are used because it can do "nearest" lookups *very* quickly, and
what we want is the nearest loads/stores using the DFS entry/exit numbers
of each statement as ordered in the dominator tree as coordinates.
On Mon, Sep 29, 2014 at 5:00 PM, Robin Morisset <morisset at google.com> wrote:
> I don't think I know this code well enough to give the LGTM, but the
> general approach looks good.
> Also, thank you for the detailed testing/explanation.
> I just have a few questions/comments:
> - You say that there were no regressions in the test-suite. Was there any
> compile-time improvement ?
> - From my understanding of your patch, it makes the limit in GVN
> redundant. If so, could the limit in GVN be removed ? It looks especially
> brittle to have a magic number in GVN, that just happens to be the same as
> a named limit in MemoryDependencyAnalysis and does exactly the same job.
> - Have you tried different values for the limit (not super important, it
> was maybe already tuned before adding to GVN, but I could not find quickly
> its history in the log) ?
> nitpick: it is easier to review changes in Phabricator if all the context
> is included. This is normally done automatically when using arcanist, but
> can also be had with git/svn:
> git diff -U999999 other-branch
> svn diff --diff-cmd=diff -x -U999999
> (from http://llvm.org/docs/Phabricator.html)
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits