| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
present in the bottom of the CFG triangle, as the transformation isn't
ever valuable if the branch can't be eliminated.
Also, unify some heuristics between SimplifyCFG's multiple
if-converters, for consistency.
This fixes rdar://10627242.
llvm-svn: 147630
|
| |
|
|
|
|
| |
global initializers if there's an implied extension or truncation.
llvm-svn: 147625
|
| |
|
|
|
|
|
|
| |
code can incorrectly move the load across a store. This never
happens in practice today, but only because the current
heuristics accidentally preclude it.
llvm-svn: 147623
|
| |
|
|
| |
llvm-svn: 147580
|
| |
|
|
|
|
| |
nsw bits on them.
llvm-svn: 147528
|
| |
|
|
|
|
|
|
| |
"phony" insertion point.
Fixes rdar://10619599: "SelectionDAGBuilder shouldn't visit PHI nodes!" assert
llvm-svn: 147439
|
| |
|
|
|
|
|
| |
'and' that would zero out the trailing bits, and to produce an exact shift
ourselves.
llvm-svn: 147391
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
captured. This allows the tracker to look at the specific use, which may be
especially interesting for function calls.
Use this to fix 'nocapture' deduction in FunctionAttrs. The existing one does
not iterate until a fixpoint and does not guarantee that it produces the same
result regardless of iteration order. The new implementation builds up a graph
of how arguments are passed from function to function, and uses a bottom-up walk
on the argument-SCCs to assign nocapture. This gets us nocapture more often, and
does so rather efficiently and independent of iteration order.
llvm-svn: 147327
|
| |
|
|
| |
llvm-svn: 147291
|
| |
|
|
|
|
|
| |
to discard weights when appropriate. Still more to do (and a new TODO), but
it's a start!
llvm-svn: 147286
|
| |
|
|
| |
llvm-svn: 147280
|
| |
|
|
|
|
| |
This is a result of Benjamin's work on ValueTracking.
llvm-svn: 147259
|
| |
|
|
|
|
|
|
|
| |
x is smaller than 2^n and it fuses with a following add.
This was intended to undo the sub canonicalization in cases where it's not profitable, but it also
finds some cases on it's own.
llvm-svn: 147256
|
| |
|
|
|
|
|
|
|
| |
undef zero.
unsigned foo(unsigned x) { return 31 - __builtin_clz(x); }
now compiles into a single "bsrl" instruction on x86.
llvm-svn: 147255
|
| |
|
|
|
|
|
|
|
|
|
| |
smaller than 2^n.
This has the obvious advantage of being commutable and is always a win on x86 because
const - x wastes a register there. On less weird architectures this may lead to
a regression because other arithmetic doesn't fuse with it anymore. I'll address that
problem in a followup.
llvm-svn: 147254
|
| |
|
|
| |
llvm-svn: 147223
|
| |
|
|
|
|
|
|
|
|
| |
time regressions. In general, it is beneficial to compile-time.
Original commit message:
Fix for bug #11429: Wrong behaviour for switches. Small improvement for code
size heuristics.
llvm-svn: 147175
|
| |
|
|
|
|
| |
Fixes PR11640.
llvm-svn: 147144
|
| |
|
|
|
|
|
|
|
|
|
| |
performance regressions (both execution-time and compile-time) on our
nightly testers.
Original commit message:
Fix for bug #11429: Wrong behaviour for switches. Small improvement for code
size heuristics.
llvm-svn: 147131
|
| |
|
|
| |
llvm-svn: 147036
|
| |
|
|
| |
llvm-svn: 146951
|
| |
|
|
|
|
| |
attribute themselve.
llvm-svn: 146851
|
| |
|
|
|
|
| |
Hope I did this correctly :)
llvm-svn: 146834
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
depending on previous branch on same comparison operands.
For example,
if (a == b) {
if (a > b) // this is false
Fixes some of the issues on <rdar://problem/10554090>
llvm-svn: 146822
|
| |
|
|
|
|
| |
These can be reduced to "~cond & x" or "~cond | x"
llvm-svn: 146624
|
| |
|
|
|
|
| |
header is a landing pad correctly (by splitting the landingpad out of the loop header). Make some adjustments to the rest of LoopSimplify to make it clear that the rest of LoopSimplify isn't making bad assumptions about the presence of landing pads. PR11575.
llvm-svn: 146621
|
| |
|
|
|
|
|
|
|
| |
into Analysis as a standalone function, since there's no need for
it to be in VMCore. Also, update it to use isKnownNonZero and
other goodies available in Analysis, making it more precise,
enabling more aggressive optimization.
llvm-svn: 146610
|
| |
|
|
| |
llvm-svn: 146597
|
| |
|
|
|
|
| |
size heuristics.
llvm-svn: 146578
|
| |
|
|
|
|
| |
point to ARC-managed pointers sometimes. This fixes rdar://10551239.
llvm-svn: 146577
|
| |
|
|
| |
llvm-svn: 146411
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I followed three heuristics for deciding whether to set 'true' or
'false':
- Everything target independent got 'true' as that is the expected
common output of the GCC builtins.
- If the target arch only has one way of implementing this operation,
set the flag in the way that exercises the most of codegen. For most
architectures this is also the likely path from a GCC builtin, with
'true' being set. It will (eventually) require lowering away that
difference, and then lowering to the architecture's operation.
- Otherwise, set the flag differently dependending on which target
operation should be tested.
Let me know if anyone has any issue with this pattern or would like
specific tests of another form. This should allow the x86 codegen to
just iteratively improve as I teach the backend how to differentiate
between the two forms, and everything else should remain exactly the
same.
llvm-svn: 146370
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Brendon Cahoon!
This extends the existing LoopUnroll and LoopUnrollPass. Brendon
measured no regressions in the llvm test suite with -unroll-runtime
enabled. This implementation works by using the existing loop
unrolling code to unroll the loop by a power-of-two (default 8). It
generates an if-then-else sequence of code prior to the loop to
execute the extra iterations before entering the unrolled loop.
llvm-svn: 146245
|
| |
|
|
|
|
| |
trivially infinite.
llvm-svn: 146197
|
| |
|
|
|
|
|
|
|
| |
It's always good to prune early, but formulae that are unsatisfactory
in their own right need to be removed before running any other pruning
heuristics. We easily avoid generating such formulae, but we need them
as an intermediate basis for forming other good formulae.
llvm-svn: 145906
|
| |
|
|
|
|
|
|
| |
don't do this now, but add a test case to prevent this from happening in the
future.
Additional test for rdar://9892684
llvm-svn: 145879
|
| |
|
|
|
|
|
|
| |
where this would be bad as the backend shouldn't have a problem inlining small
memcpys.
rdar://10510150
llvm-svn: 145865
|
| |
|
|
| |
llvm-svn: 145801
|
| |
|
|
|
|
|
|
|
|
| |
causing the optimisation to occur
Turns out long long + unsigned long long is unsigned. Doh!
Fixes http://llvm.org/bugs/show_bug.cgi?id=11455
llvm-svn: 145731
|
| |
|
|
|
|
| |
rdar://10514247
llvm-svn: 145730
|
| |
|
|
|
|
| |
rdar://10500969
llvm-svn: 145639
|
| |
|
|
|
|
| |
style issues and confusing comment
llvm-svn: 145618
|
| |
|
|
| |
llvm-svn: 145570
|
| |
|
|
|
|
|
|
| |
(val != 0) == (-val != 0) so "abs(val) != 0" becomes "val != 0"
Fixes <rdar://problem/10482509>
llvm-svn: 145563
|
| |
|
|
| |
llvm-svn: 145484
|
| |
|
|
|
|
| |
Fixes PR11431: SCEVExpander::expandAddRecExprLiterally(const llvm::SCEVAddRecExpr*): Assertion `(!isa<Instruction>(Result) || SE.DT->dominates(cast<Instruction>(Result), Builder.GetInsertPoint())) && "postinc expansion does not dominate use"' failed.
llvm-svn: 145482
|
| |
|
|
|
|
|
|
| |
(fptrunc (sqrt (fpext x))) -> (sqrtf x) transformation if -fno-builtin is
specified.
rdar://10466410
llvm-svn: 145460
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
weak variable are compiled by different compilers, such as GCC and LLVM, while
LLVM may increase the alignment to the preferred alignment there is no reason to
think that GCC will use anything more than the ABI alignment. Since it is the
GCC version that might end up in the final program (as the linkage is weak), it
is wrong to increase the alignment of loads from the global up to the preferred
alignment as the alignment might only be the ABI alignment.
Increasing alignment up to the ABI alignment might be OK, but I'm not totally
convinced that it is. It seems better to just leave the alignment of weak
globals alone.
llvm-svn: 145413
|
| |
|
|
|
|
| |
SCEV can't optimize undef in all cases, which is a separate issue from this test case.
llvm-svn: 145343
|
| |
|
|
| |
llvm-svn: 145316
|