[llvm] r261430 - When MemoryDependenceAnalysis hits a CFG with many transparent blocks,
Joerg Sonnenberger via llvm-commits
llvm-commits at lists.llvm.org
Sun May 1 11:44:23 PDT 2016
On Mon, Feb 22, 2016 at 11:03:09AM -0800, Hans Wennborg wrote:
> >>> New Revision: 261430
> >>>
> >>> URL: http://llvm.org/viewvc/llvm-project?rev=261430&view=rev
> >>> Log:
> >>> When MemoryDependenceAnalysis hits a CFG with many transparent blocks,
> >>> the algorithm easily degrades into quadratic memory and time complexity.
> >>> The easiest example is a long chain of BBs that don't otherwise use a
> >>> location. The caching will add an entry for every intermediate block and
> >>> limiting the number of results doesn't help as no results are produced
> >>> until a definition is found.
> >>>
> >>> Introduce a limit similar to the existing instructions-per-block limit.
> >>> This limit counts the total number of blocks checked. If the limit is
> >>> reached, entries are considered unknown. The initial value is 1000,
> >>> which avoids regressions for normal sized functions while still
> >>> limiting edge cases to reasnable memory consumption and execution time.
> >>>
> >>> Differential Revision: http://reviews.llvm.org/D16123
> >>
> >> Hello Hans,
> >> as mentioned on IRC the other day, I would like to see this merged into
> >> the 3.8 branch after the 3.8.0 release is cut. It fixes some long
> >> standing issues, but not regressions from earlier releases.
> >
> > I do not believe this should be merged into 3.8.
>
> FWIW, I'm not considering this for 3.8.0 either, but what we said on
> IRC was that it might be a candidate for 3.8.1 if Tom finds it
> appropriate. In any case, it should get properly reviewed first.
Hi Tom,
this has been in the tree for while now without any issues. I've been
running with the merge for a while and it has helped to avoid the
problems it was supposed to address. Can it be merged, please?
Joerg
More information about the llvm-commits
mailing list