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

[Philip Reames via llvm-commits]

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.
Quoting from my comment on the bug several days before this landed:
"Hm, given the investigation you've done, I am okay letting this land in 
ToT. I still don't *like* it, but you've done the work to show there's 
no better option with the current algorithm. However, I'm really not 
sure this should go into 3.8. We're fairly late in the release cycle and 
this change could have unexpected interactions. (Less optimization 
before other passes run, poor performance on key benchmarks, etc..)"

You have not responded to these concerns.  I do not believe this should 
be merged into 3.8.

Philip