[llvm] r261430 - When MemoryDependenceAnalysis hits a CFG with many transparent blocks,
Philip Reames via llvm-commits
llvm-commits at lists.llvm.org
Mon Feb 22 10:41:10 PST 2016
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
More information about the llvm-commits
mailing list