[llvm] r261430 - When MemoryDependenceAnalysis hits a CFG with many transparent blocks,

Hans Wennborg via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 22 11:03:09 PST 2016

On Mon, Feb 22, 2016 at 10:41 AM, Philip Reames
<listmail at philipreames.com> wrote:
> On 02/20/2016 12:31 PM, Joerg Sonnenberger via llvm-commits wrote:
>> On Sat, Feb 20, 2016 at 11:24:44AM -0000, Joerg Sonnenberger via
>> llvm-commits wrote:
>>> Author: joerg
>>> Date: Sat Feb 20 05:24:44 2016
>>> 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.


More information about the llvm-commits mailing list