Chandler Carruth c537759a7f [SROA] Fix another instability in SROA with respect to the slice ... ordering. The fundamental problem that we're hitting here is that the use-def chain ordering is *itself* not a stable thing to be relying on in the rewriting for SROA. Further, we use a non-stable sort over the slices to arrange them based on the section of the alloca they're operating on. With a debugging STL implementation (or different implementations in stage2 and stage3) this can cause stage2 != stage3. The specific aspect of this problem fixed in this commit deals with the rewriting and load-speculation around PHIs and Selects. This, like many other aspects of the use-rewriting in SROA, is really part of the "strong SSA-formation" that is doen by SROA where it works very hard to canonicalize loads and stores in *just* the right way to satisfy the needs of mem2reg[1]. When we have a select (or a PHI) with 2 uses of the same alloca, we test that loads downstream of the select are speculatable around it twice. If only one of the operands to the select needs to be rewritten, then if we get lucky we rewrite that one first and the select is immediately speculatable. This can cause the order of operand visitation, and thus the order of slices to be rewritten, to change an alloca from promotable to non-promotable and vice versa. The fix is to defer all of the speculation until *after* the rewrite phase is done. Once we've rewritten everything, we can accurately test for whether speculation will work (once, instead of twice!) and the order ceases to matter. This also happens to simplify the other subtlety of speculation -- we need to *not* speculate anything unless the result of speculating will make the alloca fully promotable by mem2reg. I had a previous attempt at simplifying this, but it was still pretty horrible. There is actually already a *really* nice test case for this in basictest.ll, but on multiple STL implementations and inputs, we just got "lucky". Fortunately, the test case is very small and we can essentially build it in exactly the opposite way to get reasonable coverage in both directions even from normal STL implementations. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202092 91177308-0d34-0410-b5e6-96231b3b80d8		2014-02-25 00:07:09 +00:00
..
Hello	Set LLVM_EXPORTED_SYMBOL_FILE in CMakeLists whose corresponding Makefiles do so.	2013-12-29 23:06:49 +00:00
InstCombine	Make some DataLayout pointers const.	2014-02-24 23:12:18 +00:00
Instrumentation	Make some DataLayout pointers const.	2014-02-24 23:12:18 +00:00
IPO	Make some DataLayout pointers const.	2014-02-24 23:12:18 +00:00
ObjCARC	Update optimization passes to handle inalloca arguments	2014-01-28 02:38:36 +00:00
Scalar	[SROA] Fix another instability in SROA with respect to the slice	2014-02-25 00:07:09 +00:00
Utils	Rename a few more DataLayout variables.	2014-02-21 01:53:35 +00:00
Vectorize	Make some DataLayout pointers const.	2014-02-24 23:12:18 +00:00
CMakeLists.txt	Extracted ObjCARC.cpp into its own library libLLVMObjCARCOpts in preparation for refactoring the ARC Optimizer.	2013-01-28 01:35:51 +00:00
LLVMBuild.txt	Extracted ObjCARC.cpp into its own library libLLVMObjCARCOpts in preparation for refactoring the ARC Optimizer.	2013-01-28 01:35:51 +00:00
Makefile	Extracted ObjCARC.cpp into its own library libLLVMObjCARCOpts in preparation for refactoring the ARC Optimizer.	2013-01-28 01:35:51 +00:00