- Sep 25, 2010
-
-
Eric Christopher authored
of the source, not the original alignment since it may no longer be valid. Fixes rdar://8400094 llvm-svn: 114781
-
- Sep 24, 2010
-
-
Michael J. Spencer authored
llvm-svn: 114750
-
- Sep 23, 2010
-
-
Bob Wilson authored
"external" even when doing lazy bitcode loading. This was broken because a function that is not materialized fails the !isDeclaration() test. llvm-svn: 114666
-
Evan Cheng authored
break critical edges on demand. llvm-svn: 114633
-
- Sep 22, 2010
-
-
Bob Wilson authored
truncates are free only in the case where the extended type is legal but the load type is not. If both types are illegal, such as when they are too big, the load may not be legalized into an extended load. llvm-svn: 114568
-
- Sep 21, 2010
-
-
Bob Wilson authored
load when the type of the load is not legal, even if truncates are not free. The load is going to be legalized to an extending load anyway. llvm-svn: 114488
-
Bob Wilson authored
llvm-svn: 114487
-
- Sep 18, 2010
-
-
Gabor Greif authored
llvm-svn: 114278
-
Gabor Greif authored
llvm-svn: 114277
-
- Sep 16, 2010
-
-
Owen Anderson authored
to optimize unreachable blocks. llvm-svn: 114105
-
Dale Johannesen authored
walking the asm arguments once and stashing their Values. This is wrong because the same memory location can be in the list twice, and if the first one has a sunkaddr substituted, the stashed value for the second one will be wrong (use-after-free). PR 8154. llvm-svn: 114104
-
- Sep 15, 2010
-
-
Chris Lattner authored
attribute(used). llvm-svn: 113911
-
- Sep 14, 2010
-
-
Owen Anderson authored
on by default and has received significant testing. llvm-svn: 113852
-
Chris Lattner authored
deleted. Fix this by doing the copyValue's before we delete stuff! The testcase only repros the problem on my system with valgrind. llvm-svn: 113820
-
Michael J. Spencer authored
This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
-
- Sep 13, 2010
-
-
Eric Christopher authored
llvm-svn: 113769
-
John Thompson authored
llvm-svn: 113766
-
Owen Anderson authored
to expose greater opportunities for store narrowing in codegen. This patch fixes a potential infinite loop in instcombine caused by one of the introduced transforms being overly aggressive. llvm-svn: 113763
-
- Sep 12, 2010
-
-
Eric Christopher authored
on to Owen. llvm-svn: 113720
-
- Sep 11, 2010
-
-
Owen Anderson authored
This can result in increased opportunities for store narrowing in code generation. Update a number of tests for this change. This fixes <rdar://problem/8285027>. Additionally, because this inverts the order of ors and ands, some patterns for optimizing or-of-and-of-or no longer fire in instances where they did originally. Add a simple transform which recaptures most of these opportunities: if we have an or-of-constant-or and have failed to fold away the inner or, commute the order of the two ors, to give the non-constant or a chance for simplification instead. llvm-svn: 113679
-
Gabor Greif authored
llvm-svn: 113647
-
- Sep 10, 2010
-
-
Michael J. Spencer authored
llvm-svn: 113632
-
Benjamin Kramer authored
llvm-svn: 113608
-
Owen Anderson authored
Lower the unrolling theshold to 150. Empirical tests indicate that this is a sweet spot in the performance per code size increase curve. llvm-svn: 113595
-
- Sep 09, 2010
-
-
Owen Anderson authored
not unrolling loops that contain calls that would be better off getting inlined. This mostly comes up when an interleaved devirtualization pass has devirtualized a call which the inliner will inline on a future pass. Thus, rather than blocking all loops containing calls, add a metric for "inline candidate calls" and block loops containing those instead. llvm-svn: 113535
-
Owen Anderson authored
Revert r113439, which relaxed the requirement that loops containing calls cannot be unrolled. After some discussion, there seems to be a better way to achieve the same effect. llvm-svn: 113528
-
Owen Anderson authored
llvm-svn: 113527
-
Owen Anderson authored
llvm-svn: 113526
-
Owen Anderson authored
Next step is to recalculate the threshold values given this new heuristic. llvm-svn: 113525
-
Owen Anderson authored
Relax the "don't unroll loops containing calls" rule. Instead, when a loop contains a call, lower the unrolling threshold to the optimize-for-size threshold. Basically, for loops containing calls, unrolling can still be profitable as long as the loop is REALLY small. llvm-svn: 113439
-
Owen Anderson authored
Generalize instcombine's support for combining multiple bit checks into a single test. Patch by Dirk Steinke! llvm-svn: 113423
-
- Sep 08, 2010
-
-
Owen Anderson authored
The threshold value of 50 is arbitrary, and I chose it simply by analogy to the inlining thresholds, where the baseline unrolling threshold is slightly smaller than the baseline inlining threshold. This could undoubtedly use some tuning. llvm-svn: 113306
-
- Sep 07, 2010
-
-
Chris Lattner authored
turning (fptrunc (sqrt (fpext x))) -> (sqrtf x) is great, but we have to delete the original sqrt as well. Not doing so causes us to do two sqrt's when building with -fmath-errno (the default on linux). llvm-svn: 113260
-
Nick Lewycky authored
Switch from isWeakForLinker to mayBeOverridden which is more accurate. Add more statistics and debugging info. Add comments. Move static function outside anonymous namespace. llvm-svn: 113190
-
- Sep 06, 2010
-
-
Chris Lattner authored
llvm-svn: 113146
-
Chris Lattner authored
in the duplicated block instead of duplicating them. Duplicating them into the end of the loop and the preheader means that we got a phi node in the header of the loop, which prevented LICM from hoisting them. GVN would usually come around later and merge the duplicated instructions so we'd get reasonable output... except that anything dependent on the shoulda-been-hoisted value can't be hoisted. In PR5319 (which this fixes), a memory value didn't get promoted. llvm-svn: 113134
-
Chris Lattner authored
Loop::hasLoopInvariantOperands method. Remove a useless and confusing Loop::isLoopInvariant(Instruction) method, which didn't do what you thought it did. No functionality change. llvm-svn: 113133
-
- Sep 05, 2010
-
-
Chris Lattner authored
llvm-svn: 113115
-
Chris Lattner authored
llvm-svn: 113114
-
Chris Lattner authored
llvm-svn: 113113
-