| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
alignment of the return type. Teach the optimizers this.
llvm-svn: 165226
|
|
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767
llvm-svn: 164768
|
|
|
|
| |
llvm-svn: 164767
|
|
|
|
|
|
| |
Reviewed offline by chandlerc.
llvm-svn: 162623
|
|
|
|
|
|
| |
Thanks Duncan for the idea
llvm-svn: 159687
|
|
|
|
| |
llvm-svn: 156558
|
|
|
|
|
|
| |
known zero in the LHS. Fixes PR12541.
llvm-svn: 155818
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
speculate. Without this, loop rotate (among many other places) would
suddenly stop working in the presence of debug info. I found this
looking at loop rotate, and have augmented its tests with a reduction
out of a very hot loop in yacr2 where failing to do this rotation costs
sometimes more than 10% in runtime performance, perturbing numerous
downstream optimizations.
This should have no impact on performance without debug info, but the
change in performance when debug info is enabled can be extreme. As
a consequence (and this how I got to this yak) any profiling of
performance problems should be treated with deep suspicion -- they may
have been wildly innacurate of debug info was enabled for profiling. =/
Just a heads up.
llvm-svn: 154263
|
|
|
|
|
|
|
|
| |
This allows us to keep passing reduced masks to SimplifyDemandedBits, but
know about all the bits if SimplifyDemandedBits fails. This allows instcombine
to simplify cases like the one in the included testcase.
llvm-svn: 154011
|
|
|
|
|
|
|
|
| |
This is the CodeGen equivalent of r153747. I tested that there is not noticeable
performance difference with any combination of -O0/-O2 /-g when compiling
gcc as a single compilation unit.
llvm-svn: 153817
|
|
|
|
|
|
| |
caused the slowdown last time.
llvm-svn: 153747
|
|
|
|
|
|
|
|
| |
Original commit message for r153521 (aka r153423):
Use the new range metadata in computeMaskedBits and add a new optimization to
instruction simplify that lets us remove an and when loding a boolean value.
llvm-svn: 153587
|
|
|
|
|
|
|
|
|
|
| |
undefined behavior, which Rafael was kind enough to fix.
Original commit message for r153423:
Use the new range metadata in computeMaskedBits and add a new optimization to
instruction simplify that lets us remove an and when loding a boolean value.
llvm-svn: 153521
|
|
|
|
|
|
|
|
| |
Original commit message:
Use the new range metadata in computeMaskedBits and add a new optimization to
instruction simplify that lets us remove an and when loading a boolean value.
llvm-svn: 153452
|
|
|
|
|
|
| |
instruction simplify that lets us remove an and when loding a boolean value.
llvm-svn: 153423
|
|
|
|
|
|
|
|
| |
overflow checking multiply intrinsic as well.
Add a test for this, updating the test from grep to FileCheck.
llvm-svn: 153028
|
|
|
|
|
|
| |
it to analyze extractvalue(llvm.[us](add|sub).with.overflow.*) intrinsics!
llvm-svn: 152398
|
|
|
|
|
|
| |
until after other inexpensive tests.
llvm-svn: 152195
|
|
|
|
| |
llvm-svn: 152070
|
|
|
|
| |
llvm-svn: 152066
|
|
|
|
|
|
| |
instead of always using ConstantVector.
llvm-svn: 149912
|
|
|
|
|
|
|
| |
were no 'unwind' instructions being generated before this, so this is in effect
a no-op.
llvm-svn: 149906
|
|
|
|
|
|
|
|
|
| |
but with a critical fix to the SelectionDAG code that optimizes copies
from strings into immediate stores: the previous code was stopping reading
string data at the first nul. Address this by adding a new argument to
llvm::getConstantStringInfo, preserving the behavior before the patch.
llvm-svn: 149800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test to fail.
These are:
r149348
r149351
r149352
r149354
r149356
r149357
r149361
r149362
r149364
r149365
llvm-svn: 149470
|
|
|
|
| |
llvm-svn: 149356
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
kicking in the big win of ConstantDataArray. As part of this, change
the implementation of GetConstantStringInfo in ValueTracking to work
with ConstantDataArray (and not ConstantArray) making it dramatically,
amazingly, more efficient in the process and renaming it to
getConstantStringInfo.
This keeps around a GetConstantStringInfo entrypoint that (grossly)
forwards to getConstantStringInfo and constructs the std::string
required, but existing clients should move over to
getConstantStringInfo instead.
llvm-svn: 149351
|
|
|
|
|
|
|
|
| |
we're at it, allow PatternMatch's "neg" pattern to match integer
vector negations, and enhance ComputeNumSigned bits to handle
shl of vectors.
llvm-svn: 149082
|
|
|
|
| |
llvm-svn: 148934
|
|
|
|
| |
llvm-svn: 148897
|
|
|
|
| |
llvm-svn: 148790
|
|
|
|
|
|
|
| |
Values, rather than just Instructions, since it's interesting
for ConstantExprs too.
llvm-svn: 147560
|
|
|
|
|
|
| |
it to simplify a few matchers.
llvm-svn: 147403
|
|
|
|
|
|
|
|
|
| |
undef zero.
unsigned foo(unsigned x) { return 31 - __builtin_clz(x); }
now compiles into a single "bsrl" instruction on x86.
llvm-svn: 147255
|
|
|
|
| |
llvm-svn: 147036
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 145801
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
duplicating the logic for globals. Make llvm::ComputeMaskedBits handle GlobalVariables slightly more aggressively, to match what InferPtrAlignment knew how to do.
llvm-svn: 145304
|
|
|
|
|
|
|
|
| |
and positive: positive, because it could be directly computed to be positive;
negative, because the nsw flags means it is either negative or undefined (the
multiplication always overflowed).
llvm-svn: 145104
|
|
|
|
|
|
| |
For completeness - not spotted in the wild.
llvm-svn: 143211
|
|
|
|
|
|
|
|
|
|
|
| |
using BinaryOperator (which only works for instructions) when it should have
been a cast to OverflowingBinaryOperator (which also works for constants).
While there, correct a few other dubious looking uses of BinaryOperator.
Thanks to Chad Rosier for the testcase. Original commit message:
My super-optimizer noticed that we weren't folding this expression to
true: (x *nsw x) sgt 0, where x = (y | 1). This occurs in 464.h264ref.
llvm-svn: 143125
|
|
|
|
|
|
| |
behind a compile failure on 483.xalancbmk.
llvm-svn: 143102
|
|
|
|
|
|
| |
in 403.gcc and was spotted by my super-optimizer.
llvm-svn: 143054
|
|
|
|
|
|
| |
true: (x *nsw x) sgt 0, where x = (y | 1). This occurs in 464.h264ref.
llvm-svn: 143028
|
|
|
|
|
|
| |
correctly in GetStringLength, fixing PR11181!
llvm-svn: 142558
|
|
|
|
|
|
|
|
| |
previously explicit non-default constructors were used.
Mostly mechanical with some manual reformatting.
llvm-svn: 135390
|
|
|
|
| |
llvm-svn: 135375
|
|
|
|
| |
llvm-svn: 135040
|
|
|
|
|
|
| |
passes as well.
llvm-svn: 133904
|