Chris Lattner 6c3ee0f3c9 Fix PR8735, a really terrible problem in the inliner's "alloca merging" ... optimization. Consider: static void foo() { A = alloca ... } static void bar() { B = alloca ... call foo(); } void main() { bar() } The inliner proceeds bottom up, but lets pretend it decides not to inline foo into bar. When it gets to main, it inlines bar into main(), and says "hey, I just inlined an alloca "B" into main, lets remember that. Then it keeps going and finds that it now contains a call to foo. It decides to inline foo into main, and says "hey, foo has an alloca A, and I have an alloca B from another inlined call site, lets reuse it". The problem with this of course, is that the lifetime of A and B are nested, not disjoint. Unfortunately I can't create a reasonable testcase for this: the one in the PR is both huge and extremely sensitive, because you minor tweaks end up causing foo to get inlined into bar too early. We already have tests for the basic alloca merging optimization and this does not break them. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120995 91177308-0d34-0410-b5e6-96231b3b80d8		2010-12-06 07:52:42 +00:00
..
Hello
InstCombine	PR5207: Rename overloaded APInt methods set(), clear(), flip() to	2010-12-01 08:53:58 +00:00
Instrumentation	Get rid of static constructors for pass registration. Instead, every pass exposes an initializeMyPassFunction(), which	2010-10-19 17:21:58 +00:00
IPO	Fix PR8735, a really terrible problem in the inliner's "alloca merging"	2010-12-06 07:52:42 +00:00
Scalar	Fix PR8728, a miscompilation I recently introduced. When optimizing	2010-12-06 01:48:06 +00:00
Utils	improve comment	2010-12-06 07:43:04 +00:00
Makefile