| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
needing to mention the size.
llvm-svn: 216158
|
| |
|
|
|
|
| |
Adapted from a patch by Richard Smith, test-case written by me.
llvm-svn: 216157
|
| |
|
|
|
|
| |
If we have a scalar reduction, we can increase the critical path length if the loop we're unrolling is inside another loop. Limit, by default to 2, so the critical path only gets increased by one reduction operation.
llvm-svn: 216140
|
| |
|
|
|
|
| |
C2), C3) to (icmp ult/ule ((A & ~(C1 ^ C2)) + max(C1, C2)), C3) under certain condition
llvm-svn: 216135
|
| |
|
|
|
|
|
| |
We can prove that a 'sub' can be a 'sub nuw' if the left-hand side is
negative and the right-hand side is non-negative.
llvm-svn: 216045
|
| |
|
|
|
|
|
|
|
| |
Because declarations of these functions can appear in places like autoconf
checks, they have to be handled somehow, even though we do not support
vararg custom functions. We do so by printing a warning and calling the
uninstrumented function, as we do for unimplemented functions.
llvm-svn: 216042
|
| |
|
|
|
|
|
|
|
|
| |
We can prove that a 'sub' can be a 'sub nsw' under certain conditions:
- The sign bits of the operands is the same.
- Both operands have more than 1 sign bit.
The subtraction cannot be a signed overflow in either case.
llvm-svn: 216037
|
| |
|
|
|
|
| |
This reverts commit r215994 because MSVC 2012 can't cope with its C++11 goodness.
llvm-svn: 215999
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the hint mechanism relied on clean up passes to remove redundant
metadata, which still showed up if running opt at low levels of optimization.
That also has shown that multiple nodes of the same type, but with different
values could still coexist, even if temporary, and cause confusion if the
next pass got the wrong value.
This patch makes sure that, if metadata already exists in a loop, the hint
mechanism will never append a new node, but always replace the existing one.
It also enhances the algorithm to cope with more metadata types in the future
by just adding a new type, not a lot of code.
llvm-svn: 215994
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Proof using CVC3 follows:
$ cat t.cvc
A, B : BITVECTOR(32);
QUERY BVXOR((A & ~B),(~A & B)) = BVXOR(A,B);
$ cvc3 t.cvc
Valid.
Differential Revision: http://reviews.llvm.org/D4898
llvm-svn: 215974
|
| |
|
|
| |
llvm-svn: 215973
|
| |
|
|
| |
llvm-svn: 215970
|
| |
|
|
|
|
|
|
| |
avoid needing to mention the size."
Getting a weird buildbot failure that I need to investigate.
llvm-svn: 215870
|
| |
|
|
|
|
| |
needing to mention the size.
llvm-svn: 215868
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
(select y, x, 0.0) when the multiply has fast math flags set.
While this might seem like an obvious canonicalization, there is one subtle problem with it. The result of the original expression
is undef when x is NaN (remember, fast math flags), but the result of the select is always defined when x is NaN. This means that the
new expression is strictly more defined than the original one. One unfortunate consequence of this is that the transform is not reversible!
It's always legal to make increase the defined-ness of an expression, but it's not legal to reduce it. Thus, targets that prefer the original
form of the expression cannot reverse the transform to recover it. Another way to think of it is that the transform has lost source-level
information (the fast math flags), which is undesirable.
llvm-svn: 215825
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While *most* (X sdiv 1) operations will get caught by InstSimplify, it
is still possible for a sdiv to appear in the worklist which hasn't been
simplified yet.
This means that it is possible for 0 - (X sdiv 1) to get transformed
into (X sdiv -1); dividing by -1 can make the transform produce undef
values instead of the proper result.
Sorry for the lack of testcase, it's a bit problematic because it relies
on the exact order of operations in the worklist.
llvm-svn: 215818
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can combne a mul with a div if one of the operands is a multiple of
the other:
%mul = mul nsw nuw %a, C1
%ret = udiv %mul, C2
=>
%ret = mul nsw %a, (C1 / C2)
This can expose further optimization opportunities if we end up
multiplying or dividing by a power of 2.
Consider this small example:
define i32 @f(i32 %a) {
%mul = mul nuw i32 %a, 14
%div = udiv exact i32 %mul, 7
ret i32 %div
}
which gets CodeGen'd to:
imull $14, %edi, %eax
imulq $613566757, %rax, %rcx
shrq $32, %rcx
subl %ecx, %eax
shrl %eax
addl %ecx, %eax
shrl $2, %eax
retq
We can now transform this into:
define i32 @f(i32 %a) {
%shl = shl nuw i32 %a, 1
ret i32 %shl
}
which gets CodeGen'd to:
leal (%rdi,%rdi), %eax
retq
This fixes PR20681.
llvm-svn: 215815
|
| |
|
|
|
|
|
|
|
| |
Replace the old code in GVN and BBVectorize with it. Update SimplifyCFG to use
it.
Patch by Björn Steinbrink!
llvm-svn: 215723
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a call site with noalias metadata is inlined, that metadata can be
propagated directly to the inlined instructions (only those that might access
memory because it is not useful on the others). Prior to inlining, the noalias
metadata could express that a call would not alias with some other memory
access, which implies that no instruction within that called function would
alias. By propagating the metadata to the inlined instructions, we preserve
that knowledge.
This should complete the enhancements requested in PR20500.
llvm-svn: 215676
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inlining
When preserving noalias function parameter attributes by adding noalias
metadata in the inliner, we should do this for general function calls (not just
memory intrinsics). The logic is very similar to what already existed (except
that we want to add this metadata even for functions taking no relevant
parameters). This metadata can be used by ModRef queries in the caller after
inlining.
This addresses the first part of PR20500. Adding noalias metadata during
inlining is still turned off by default.
llvm-svn: 215657
|
| |
|
|
|
|
|
| |
Vector instructions are (still) not supported for either integer or floating
point. Hopefully, that work will be landed shortly.
llvm-svn: 215647
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Proof using CVC3 follows:
$ cat t.cvc
A, B : BITVECTOR(32);
QUERY BVXOR((A | ~B),(~A |B)) = BVXOR(A,B);
$ cvc3 t.cvc
Valid.
Patch by Mayur Pandey!
Differential Revision: http://reviews.llvm.org/D4883
llvm-svn: 215621
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Transform ((B | C) & A) | B --> B | (A & C)
Z3 Link: http://rise4fun.com/Z3/hP6p
Patch by Sonam Kumari!
Differential Revision: http://reviews.llvm.org/D4865
llvm-svn: 215619
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
v2: continue iterating through the rest of the bb
use for loop
v3: initialize FlattenCFG pass in ScalarOps
add test
v4: split off initializing flattencfg to a separate patch
add comment
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 215574
|
| |
|
|
|
| |
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 215573
|
| |
|
|
|
|
|
|
|
|
| |
Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)
Changes made by clang-tidy with minor tweaks.
llvm-svn: 215558
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
attribute and function argument attribute synthesizing and propagating.
As with the other uses of this attribute, the goal remains a best-effort
(no guarantees) attempt to not optimize the function or assume things
about the function when optimizing. This is particularly useful for
compiler testing, bisecting miscompiles, triaging things, etc. I was
hitting specific issues using optnone to isolate test code from a test
driver for my fuzz testing, and this is one step of fixing that.
llvm-svn: 215538
|
| |
|
|
|
|
| |
I've followed up on the original commit as well.
llvm-svn: 215532
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Correctness proof of the transform using CVC3-
$ cat t.cvc
A, B : BITVECTOR(32);
QUERY BVXOR(A | B, BVXOR(A,B) ) = A & B;
$ cvc3 t.cvc
Valid.
llvm-svn: 215524
|
| |
|
|
| |
llvm-svn: 215467
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, avoid calling setTailCall(false) on musttail calls. The funciton
prototypes should be "congruent", so the shadow layout should be exactly
the same.
Second, avoid inserting instrumentation after a musttail call to
propagate the return value shadow. We don't need to propagate the
result of a tail call, it should already be in the right place.
Reviewed By: eugenis
Differential Revision: http://reviews.llvm.org/D4331
llvm-svn: 215415
|
| |
|
|
|
|
|
|
|
|
|
| |
No functional change. To be used in future commits that need to look
for such instructions.
Reviewed By: rafael
Differential Revision: http://reviews.llvm.org/D4504
llvm-svn: 215413
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
What follows bellow is a correctness proof of the transform using CVC3.
$ < t.cvc
A, B : BITVECTOR(32);
QUERY BVPLUS(32, A & B, A | B) = BVPLUS(32, A, B);
$ cvc3 < t.cvc
Valid.
llvm-svn: 215400
|
| |
|
|
| |
llvm-svn: 215200
|
| |
|
|
|
|
|
|
|
|
| |
GlobalOpt didn't know how to simulate InsertValueInst or
ExtractValueInst. Optimizing these is pretty straightforward.
N.B. This came up when looking at clang's IRGen for MS ABI member
pointers; they are represented as aggregates.
llvm-svn: 215184
|
| |
|
|
| |
llvm-svn: 215169
|
| |
|
|
|
|
| |
We were using the pointer type which is incorrect.
llvm-svn: 215162
|
| |
|
|
|
|
|
|
| |
this case, the code path dealing with vector promotion was missing the explicit
checks for lifetime intrinsics that were present on the corresponding integer
promotion path.
llvm-svn: 215148
|
| |
|
|
|
|
| |
It broke msan.
llvm-svn: 214989
|
| |
|
|
|
|
| |
This swaps the order of the loop vectorizer and the SLP/BB vectorizers. It is disabled by default so we can do performance testing - ideally we want to change to having the loop vectorizer running first, and the SLP vectorizer using its leftovers instead of the other way around.
llvm-svn: 214963
|
| |
|
|
|
|
|
| |
already have a large number of blocks. Works around a performance issue with
the greedy register allocator.
llvm-svn: 214944
|
| |
|
|
|
|
| |
Committing http://reviews.llvm.org/D4798 for Robin Morisset (morisset@google.com)
llvm-svn: 214934
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is mostly a cleanup, but it changes a fairly old behavior.
Every "real" LTO user was already disabling the silly internalize pass
and creating the internalize pass itself. The difference with this
patch is for "opt -std-link-opts" and the C api.
Now to get a usable behavior out of opt one doesn't need the funny
looking command line:
opt -internalize -disable-internalize -internalize-public-api-list=foo,bar -std-link-opts
llvm-svn: 214919
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optimize the following IR:
%1 = tail call noalias i8* @calloc(i64 1, i64 4)
%2 = bitcast i8* %1 to i32*
; This store is dead and should be removed
store i32 0, i32* %2, align 4
Memory returned by calloc is guaranteed to be zero initialized. If the value being stored is the constant zero (and the store is not otherwise observable across threads), we can delete the store. If the store is to an out of bounds address, it is undefined and thus also removable.
Reviewed By: nicholas
Differential Revision: http://reviews.llvm.org/D3942
llvm-svn: 214897
|
| |
|
|
|
|
|
|
| |
have a cost.
Some types, such as 128-bit vector types on AArch64, don't have any callee-saved registers. So if a value needs to stay live over a callsite, it must be spilled and refilled. This cost is now taken into account.
llvm-svn: 214859
|
| |
|
|
|
|
|
|
|
| |
When we have a covered lookup table, make sure we don't delete PHINodes that
are cached in PHIs.
rdar://17887153
llvm-svn: 214642
|
| |
|
|
| |
llvm-svn: 214638
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of creating global variables for source locations and global names,
just create metadata nodes and strings. They will be transformed into actual
globals in the instrumentation pass (if necessary). This approach is more
flexible:
1) we don't have to ensure that our custom globals survive all the optimizations
2) if globals are discarded for some reason, we will simply ignore metadata for them
and won't have to erase corresponding globals
3) metadata for source locations can be reused for other purposes: e.g. we may
attach source location metadata to alloca instructions and provide better descriptions
for stack variables in ASan error reports.
No functionality change.
llvm-svn: 214604
|
| |
|
|
|
|
|
|
|
|
| |
When the cost model determines vectorization is not possible/profitable these remarks print an analysis of that decision.
Note that in selectVectorizationFactor() we can assume that OptForSize and ForceVectorization are mutually exclusive.
Reviewed by Arnold Schwaighofer
llvm-svn: 214599
|
| |
|
|
|
|
|
| |
Some configure scripts declare this with the wrong prototype, which can lead
to an assertion failure.
llvm-svn: 214593
|