| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 214561
|
| |
|
|
|
|
|
|
|
| |
Instead of moving out the data in a ErrorOr<std::unique_ptr<Foo>>, get
a reference to it.
Thanks to David Blaikie for the suggestion.
llvm-svn: 214516
|
| |
|
|
| |
llvm-svn: 214496
|
| |
|
|
| |
llvm-svn: 214494
|
| |
|
|
| |
llvm-svn: 214487
|
| |
|
|
|
|
|
|
| |
operands.
This reverts r214338 (except the test file) and replaces it with a more general algorithm.
llvm-svn: 214485
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4653
llvm-svn: 214479
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4628
llvm-svn: 214478
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4652
llvm-svn: 214477
|
| |
|
|
|
|
|
|
| |
Patch Credit to Ankit Jain !
Differential Revision: http://reviews.llvm.org/D4655
llvm-svn: 214476
|
| |
|
|
|
|
|
|
| |
The current remark is ambiguous and makes it sounds like explicitly specifying vectorization will allow the loop to be vectorized. This is not the case. The improved remark directs the user to -Rpass-analysis=loop-vectorize to determine the cause of the pass-miss.
Reviewed by Arnold Schwaighofer`
llvm-svn: 214445
|
| |
|
|
|
|
|
|
| |
is not a reduction or induction variable.
Reviewed by Arnold Schwaighofer
llvm-svn: 214440
|
| |
|
|
|
|
|
|
| |
Switch array type shadow from a single integer to
an array of integers (i.e. make it per-element).
This simplifies instrumentation of extractvalue and fixes PR20493.
llvm-svn: 214398
|
| |
|
|
|
|
| |
cmpOperation has been renamed to cmpOperations (multiple form).
llvm-svn: 214392
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We can only propagate the nsw bits if both subtraction instructions are
marked with the appropriate bit.
N.B. We only propagate the nsw bit in InstCombine because the nuw case
is already handled in InstSimplify.
This fixes PR20189.
llvm-svn: 214385
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While we can already transform A | (A ^ B) into A | B, things get bad
once we have (A ^ B) | (A ^ B ^ Cst) because reassociation will morph
this into (A ^ B) | ((A ^ Cst) ^ B). Our existing patterns fail once
this happens.
To fix this, we add a new pattern which looks through the tree of xor
binary operators to see that, in fact, there exists a redundant xor
operation.
What follows bellow is a correctness proof of the transform using CVC3.
$ cat t.cvc
A, B, C : BITVECTOR(64);
QUERY BVXOR(A, B) | BVXOR(BVXOR(B, C), A) = BVXOR(A, B) | C;
QUERY BVXOR(BVXOR(A, C), B) | BVXOR(A, B) = BVXOR(A, B) | C;
QUERY BVXOR(A, B) & BVXOR(BVXOR(B, C), A) = BVXOR(A, B) & ~C;
QUERY BVXOR(BVXOR(A, C), B) & BVXOR(A, B) = BVXOR(A, B) & ~C;
$ cvc3 < t.cvc
Valid.
Valid.
Valid.
Valid.
llvm-svn: 214342
|
| |
|
|
| |
llvm-svn: 214338
|