Daniel Berlin 43dab5a5fb Make PredIteratorCache size() logically const. Do not require copying predecessors to get size. ... Summary: Every single benchmark i can run, on large and small cfgs, fully connected, etc, across 3 different platforms (x86, arm., and PPC) says that the current pred iterator cache is a losing proposition. I can't find a case where it's faster than just walking preds, and in some cases, it's 5-10% slower. This is due to copying the preds. It also degrades into copying the entire cfg. The one operation that is occasionally faster is the cached size. This makes that operation faster by not relying on having the copies available. I'm not even sure that is faster enough to be worth it. I, again, have trouble finding cases where this takes long enough in a pass to be worth caching compared to a million other things they could cache or improve. My suggestion: We next remove the get() interface. We do stronger benchmarking of size(). We probably end up killing this entire cache. / Reviewers: chandlerc Subscribers: aemerson, llvm-commits, trentxintong Differential Revision: https://reviews.llvm.org/D30873 llvm-svn: 297733		2017-03-14 11:25:45 +00:00
..
llvm	Make PredIteratorCache size() logically const. Do not require copying predecessors to get size.	2017-03-14 11:25:45 +00:00
llvm-c	[GVN] Initial check-in of a new global value numbering algorithm.	2016-12-22 16:03:48 +00:00