forked from OSchip/llvm-project
c21c100f3d
this was a tree of hashtables, and a query recursed into the table for the immediate dominator ad infinitum if the initial lookup failed. This led to really bad performance on tall, narrow CFGs. We can instead replace it with what is conceptually a multimap of value numbers to leaders (actually represented by a hashtable with a list of Value*'s as the value type), and then determine which leader from that set to use very cheaply thanks to the DFS numberings maintained by DominatorTree. Because there are typically few duplicates of a given value, this scan tends to be quite fast. Additionally, we use a custom linked list and BumpPtr allocation to avoid any unnecessary allocation in representing the value-side of the multimap. This change brings with it a 15% (!) improvement in the total running time of GVN on 403.gcc, which I think is pretty good considering that includes all the "real work" being done by MemDep as well. The one downside to this approach is that we can no longer use GVN to perform simple conditional progation, but that seems like an acceptable loss since we now have LVI and CorrelatedValuePropagation to pick up the slack. If you see conditional propagation that's not happening, please file bugs against LVI or CVP. llvm-svn: 119714 |
||
|---|---|---|
| .. | ||
| Analysis | ||
| Archive | ||
| Assembler | ||
| Bindings/Ocaml | ||
| Bitcode | ||
| BugPoint | ||
| CodeGen | ||
| DebugInfo | ||
| ExecutionEngine | ||
| Feature | ||
| FrontendAda | ||
| FrontendC | ||
| FrontendC++ | ||
| FrontendFortran | ||
| FrontendObjC | ||
| FrontendObjC++ | ||
| Integer | ||
| LLVMC | ||
| Linker | ||
| MC | ||
| Other | ||
| Scripts | ||
| TableGen | ||
| Transforms | ||
| Unit | ||
| Verifier | ||
| lib | ||
| CMakeLists.txt | ||
| Makefile | ||
| Makefile.tests | ||
| TestRunner.sh | ||
| lit.cfg | ||
| lit.site.cfg.in | ||
| site.exp.in | ||