| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 114841
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
post-dominated the block it was being hoisted to.
Splitting critical edges at the merge point only addressed part of the issue; it is also possible for non-post-domination
to occur when the path from the load to the merge has branches in it. Unfortunately, full anticipation analysis is
time-consuming, so for now approximate it. This is strictly more conservative than real anticipation, so we will miss
some cases that real PRE would allow, but we also no longer insert loads into paths where they didn't exist before. :-)
This is a very slight net positive on SPEC for me (0.5% on average). Most of the benchmarks are largely unaffected, but
when it pays off it pays off decently: 181.mcf improves by 4.5% on my machine.
llvm-svn: 114785
|
|
|
|
|
|
|
|
|
| |
of the source, not the original alignment since it may no longer
be valid.
Fixes rdar://8400094
llvm-svn: 114781
|
|
|
|
| |
llvm-svn: 114750
|
|
|
|
|
|
|
| |
"external" even when doing lazy bitcode loading. This was broken because
a function that is not materialized fails the !isDeclaration() test.
llvm-svn: 114666
|
|
|
|
|
|
| |
break critical edges on demand.
llvm-svn: 114633
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 114487
|
|
|
|
| |
llvm-svn: 114278
|
|
|
|
| |
llvm-svn: 114277
|
|
|
|
|
|
|
|
| |
time trying
to optimize unreachable blocks.
llvm-svn: 114105
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
attribute(used).
llvm-svn: 113911
|
|
|
|
|
|
| |
on by default and has received significant testing.
llvm-svn: 113852
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r113632
Conflicts:
cmake/modules/AddLLVM.cmake
llvm-svn: 113819
|
|
|
|
| |
llvm-svn: 113769
|
|
|
|
| |
llvm-svn: 113766
|
|
|
|
|
|
|
|
|
| |
instcombine transforms
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
|
|
|
|
|
|
| |
on to Owen.
llvm-svn: 113720
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the and's mask.
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
|
|
|
|
| |
llvm-svn: 113647
|
|
|
|
| |
llvm-svn: 113632
|
|
|
|
| |
llvm-svn: 113608
|
|
|
|
|
|
|
|
| |
a sweet spot in the performance per
code size increase curve.
llvm-svn: 113595
|
|
|
|
|
|
|
|
|
|
|
| |
with calls, is
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
|
|
|
|
|
|
|
|
| |
cannot be unrolled. After some discussion,
there seems to be a better way to achieve the same effect.
llvm-svn: 113528
|
|
|
|
|
|
| |
Revert it.
llvm-svn: 113527
|
|
|
|
| |
llvm-svn: 113526
|
|
|
|
|
|
|
|
| |
when we unroll a loop.
Next step is to recalculate the threshold values given this new heuristic.
llvm-svn: 113525
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
single test. Patch by Dirk Steinke!
llvm-svn: 113423
|
|
|
|
|
|
|
|
|
|
| |
optimized for size.
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 113146
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 113115
|
|
|
|
| |
llvm-svn: 113114
|
|
|
|
| |
llvm-svn: 113113
|
|
|
|
| |
llvm-svn: 113106
|
|
|
|
|
|
| |
This reduces malloc traffic (yay!) and removes MergeFunctionsEqualityInfo.
llvm-svn: 113105
|
|
|
|
|
|
|
| |
strong functions first to make sure they're the canonical definitions and then
do a second pass looking only for weak functions.
llvm-svn: 113104
|
|
|
|
| |
llvm-svn: 113073
|
|
|
|
|
|
|
| |
into an inner loop, as the new loop iteration may differ substantially.
This fixes PR8078.
llvm-svn: 113057
|
|
|
|
|
|
|
|
| |
location is being re-stored to the memory location. We would get
a dangling pointer from the SSAUpdate data structure and miss a
use. This fixes PR8068
llvm-svn: 113042
|
|
|
|
| |
llvm-svn: 113025
|
|
|
|
|
|
|
|
| |
global when it
is provable that they're equivalent. This fixes PR4855.
llvm-svn: 112994
|