| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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
|
|
|
|
|
|
|
| |
crc32.[8|16|32] have been renamed to .crc32.32.[8|16|32] and
crc64.[8|16|32] have been renamed to .crc32.64.[8|64].
llvm-svn: 132163
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aligned.
Teach memcpyopt to not give up all hope when confonted with an underaligned
memcpy feeding an overaligned byval. If the *source* of the memcpy can be
determined to be adequeately aligned, or if it can be forced to be, we can
eliminate the memcpy.
This addresses PR9794. We now compile the example into:
define i32 @f(%struct.p* nocapture byval align 8 %q) nounwind ssp {
entry:
%call = call i32 @g(%struct.p* byval align 8 %q) nounwind
ret i32 %call
}
in both x86-64 and x86-32 mode. We still don't get a tailcall though,
because tailcalls apparently can't handle byval.
llvm-svn: 131884
|
|
|
|
| |
llvm-svn: 131861
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129558
|
|
|
|
|
|
|
| |
Based on PR9429, but no testcase because I can't figure out how to trigger it
anymore given other changes to the relevant code.
llvm-svn: 128781
|
|
|
|
| |
llvm-svn: 128028
|
|
|
|
| |
llvm-svn: 127548
|
|
|
|
|
|
|
|
| |
overflow semantics as add.
Should fix the selfhost failures that started with r127463.
llvm-svn: 127465
|
|
|
|
|
|
|
| |
do with nuw here, but sub and mul should be given similar treatment.
Fixes PR9343 #15!
llvm-svn: 127463
|
|
|
|
| |
llvm-svn: 127243
|
|
|
|
|
|
|
| |
then the result could go either way. If it's provably positive then so is the
srem. Fixes PR9343 #7!
llvm-svn: 127146
|
|
|
|
| |
llvm-svn: 126645
|
|
|
|
|
|
|
| |
also have a zero when numerator = denominator. Reverts parts of r126635 and
r126637.
llvm-svn: 126644
|
|
|
|
| |
llvm-svn: 126642
|
|
|
|
|
|
| |
srem instruction.
llvm-svn: 126637
|
|
|
|
|
|
| |
them as splat values.
llvm-svn: 126041
|
|
|
|
|
|
| |
passes. Fixes PR9112. Patch by Jakub Staszak!
llvm-svn: 125319
|
|
|
|
| |
llvm-svn: 124656
|
|
|
|
| |
llvm-svn: 124533
|
|
|
|
|
|
| |
which is more efficient than countPopulation - use it.
llvm-svn: 124283
|
|
|
|
| |
llvm-svn: 124188
|
|
|
|
| |
llvm-svn: 124184
|
|
|
|
|
|
|
|
|
|
|
| |
optimized code are:
(non-negative number)+(power-of-two) != 0 -> true
and
(x | 1) != 0 -> true
Instcombine knows about the second one of course, but only does it if X|1
has only one use. These fire thousands of times in the testsuite.
llvm-svn: 124183
|
|
|
|
|
|
|
|
|
|
|
| |
with BasicAA's DecomposeGEPExpression, which recently began
using a TargetData. This fixes PR8968, though the testcase
is awkward to reduce.
Also, update several off GetUnderlyingObject's users
which happen to have a TargetData handy to pass it in.
llvm-svn: 124134
|
|
|
|
|
|
| |
ashr's with huge shift amounts, PR8896
llvm-svn: 122814
|
|
|
|
| |
llvm-svn: 122565
|
|
|
|
|
|
| |
matching psign & pblend operations to the IR produced by clang/gcc for their C idioms.
llvm-svn: 122105
|