| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
have other uses and one non-constant index
Summary:
Pointer difference simplifications currently happen only if input GEPs don't have other uses or their indexes are all constants, to avoid duplicating indexing arithmetic.
This patch enables cases with exactly one non-constant index among input GEPs to happen where there is no duplicated arithmetic or code size increase even if input GEPs have other uses.
For example, this patch allows "(&A[42][i]-&A[42][0])" --> "i", which didn't happen previously, if the input GEP(s) have other uses.
Reviewers: sanjoy, bkramer
Reviewed By: sanjoy
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D35499
llvm-svn: 309304
|
| |
|
|
| |
llvm-svn: 309192
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This changes SimplifyLibCalls to use the new OptimizationRemarkEmitter
API.
In fact, as SimplifyLibCalls is only ever called via InstCombine,
(as far as I can tell) the OptimizationRemarkEmitter is added there,
and then passed through to SimplifyLibCalls later.
I have avoided changing any remark text.
This closes PR33787
Patch by Sam Elliott!
Reviewers: anemet, davide
Reviewed By: anemet
Subscribers: davide, mehdi_amini, eraman, fhahn, llvm-commits
Differential Revision: https://reviews.llvm.org/D35608
llvm-svn: 309158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with undef.
This is a workaround for the bug described in PR31652 and
http://lists.llvm.org/pipermail/llvm-dev/2017-July/115497.html. The temporary
solution is to add a function EqualityPropUnSafe. In EqualityPropUnSafe, for
some simple patterns we can know the equality comparison may contains undef,
so we regard such comparison as unsafe and will not do loop-unswitching for
them. We also need to disable the select simplification when one of select
operand is undef and its result feeds into equality comparison.
The patch cannot clear the safety issue caused by the bug, but it can suppress
the issue from happening to some extent.
Differential Revision: https://reviews.llvm.org/D35811
llvm-svn: 309059
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Currently, when GVN creates a load and when InstCombine creates a new store for unreachable Load, the DebugLoc info gets lost.
Reviewers: dberlin, davide, aprantl
Reviewed By: aprantl
Subscribers: davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D34639
llvm-svn: 308404
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D35376
llvm-svn: 308144
|
| |
|
|
|
|
| |
This removes a dedicated matcher and allows us to support more than just an AND masking the lower bit.
llvm-svn: 308124
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handle cases where one side doesn't simplify, but the other side resolves to an identity value
Summary:
If one side simplifies to the identity value for inner opcode, we can replace the value with just the operation that can't be simplified.
I've removed a couple now unneeded special cases in visitAnd and visitOr. There are probably other cases I missed.
Reviewers: spatel, majnemer, hfinkel, dberlin
Reviewed By: spatel
Subscribers: grandinj, llvm-commits, spatel
Differential Revision: https://reviews.llvm.org/D35451
llvm-svn: 308111
|
| |
|
|
|
|
|
| |
1. Add a one-use check to prevent increasing instruction count.
2. Generalize the pattern matching to include vector types.
llvm-svn: 308105
|
| |
|
|
| |
llvm-svn: 308098
|
| |
|
|
|
|
|
| |
These patterns and tests were added to InstSimplify with:
https://reviews.llvm.org/rL303004
llvm-svn: 308096
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in:
https://bugs.llvm.org/show_bug.cgi?id=32401
we have a backend transform to undo this:
https://reviews.llvm.org/rL299542
when it's likely that the xor version leads to better codegen, but we want
this form in IR for better analysis and simplification potential.
llvm-svn: 308031
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenCL 2.0 introduces the notion of memory scopes in atomic operations to
global and local memory. These scopes restrict how synchronization is
achieved, which can result in improved performance.
This change extends existing notion of synchronization scopes in LLVM to
support arbitrary scopes expressed as target-specific strings, in addition to
the already defined scopes (single thread, system).
The LLVM IR and MIR syntax for expressing synchronization scopes has changed
to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this
replaces *singlethread* keyword), or a target-specific name. As before, if
the scope is not specified, it defaults to CrossThread/System scope.
Implementation details:
- Mapping from synchronization scope name/string to synchronization scope id
is stored in LLVM context;
- CrossThread/System and SingleThread scopes are pre-defined to efficiently
check for known scopes without comparing strings;
- Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in
the bitcode.
Differential Revision: https://reviews.llvm.org/D21723
llvm-svn: 307722
|
| |
|
|
| |
llvm-svn: 307626
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes https://bugs.llvm.org/show_bug.cgi?id=25454
Do not assume IRBuilder creates Instruction where it can create Value.
Do not assume idiom operands are constant, leave generalisation ot the IRBuilder.
Differential Revision: https://reviews.llvm.org/D35114
llvm-svn: 307554
|
| |
|
|
|
|
| |
isIntegerTy(unsigned), but also works for vectors.
llvm-svn: 307492
|
| |
|
|
|
|
| |
Type::isPtrOrPtrVectorTy/isIntOrIntVectorTy/isFPOrFPVectorTy to shorten code. NFC
llvm-svn: 307491
|
| |
|
|
|
|
|
|
|
|
| |
of PR33721 by making sure that we have integer types before doing select C, -1, 0 -> sext C to int
I recently changed m_One and m_AllOnes to use Constant::isOneValue/isAllOnesValue which work on floating point values too. The original implementation looked specifically for ConstantInt scalars and splats. So I'm guessing we are accidentally trying to issue sext/zexts on floating point types now.
Hopefully I figure out how to reproduce the failure from the PR soon.
llvm-svn: 307486
|
| |
|
|
|
|
|
|
| |
Previously the InstCombiner class contained a pointer to an IR builder that had been passed to the constructor. Sometimes this would be passed to helper functions as either a pointer or the pointer would be dereferenced to be passed by reference.
This patch makes it a reference everywhere including the InstCombiner class itself so there is more inconsistency. This a large, but mechanical patch. I've done very minimal formatting changes on it despite what clang-format wanted to do.
llvm-svn: 307451
|
| |
|
|
|
|
| |
passing the InstCombiner object. We can just ask it for the DataLayout. NFC
llvm-svn: 307333
|
| |
|
|
| |
llvm-svn: 307332
|
| |
|
|
|
|
| |
an argument and not the whole InstCombiner object. NFC
llvm-svn: 307331
|
| |
|
|
|
|
| |
to be necessary.
llvm-svn: 307295
|
| |
|
|
|
|
| |
isZero and isOne. NFCI
llvm-svn: 307293
|
| |
|
|
|
|
|
|
| |
isZero/isOne/isMinusOne instead of isNullValue/isOneValue/isAllOnesValue inherited from Constant. NFCI
Going through the Constant methods requires redetermining that the Constant is a ConstantInt and then calling isZero/isOne/isMinusOne.
llvm-svn: 307292
|
| |
|
|
|
|
| |
Builder is already a member of the InstCombiner class so we can use it with passing it.
llvm-svn: 307290
|
| |
|
|
| |
llvm-svn: 307275
|
| |
|
|
| |
llvm-svn: 307274
|
| |
|
|
|
|
|
|
|
|
|
|
| |
saving instructions
Bswap isn't a simple operation so we need to make sure we are really removing a call to it before doing these simplifications.
For the case when both LHS and RHS are bswaps I've allowed it to be moved if either LHS or RHS has a single use since that at least allows us to move it later where it might find another bswap to combine with and it decreases the use count on the other side so maybe the other user can be optimized.
Differential Revision: https://reviews.llvm.org/D34974
llvm-svn: 307273
|
| |
|
|
|
|
| |
Instead just use APInt objects and only create a ConstantInt at the end if we need it for the Offset.
llvm-svn: 307270
|
| |
|
|
|
|
|
|
| |
ICmpInst::Predicate. NFC
There isn't really an ICmpInst version so we're just accessing the CmpInst version through inheritance.
llvm-svn: 307199
|
| |
|
|
|
|
| |
InstSimplify instead. NFC
llvm-svn: 307065
|
| |
|
|
|
|
| |
Will try to fix it soon, but in case I forget.
llvm-svn: 307003
|
| |
|
|
|
|
| |
BITWISE_OP(x, BSWAP(CONSTANT) ) ) for splat vectors.
llvm-svn: 307002
|
| |
|
|
|
|
|
|
| |
BSWAP(OP(BSWAP(CONSTANT), x)).
Constants were already canonicalized to the right hand side before we got here.
llvm-svn: 307000
|
| |
|
|
|
|
| |
for vectors.
llvm-svn: 306999
|
| |
|
|
|
|
| |
Replace with an assert. NFC
llvm-svn: 306997
|
| |
|
|
| |
llvm-svn: 306986
|
| |
|
|
|
|
|
|
|
| |
We assumed the constant was a scalar when creating the replacement operand.
Also, improve tests for this fold and move the tests for this fold to their own file.
I'll move the related and missing tests to this file as a follow-up.
llvm-svn: 306985
|
| |
|
|
|
|
|
|
|
| |
I noticed this missed bswap optimization in the CGP memcmp() expansion,
and then I saw that we don't have the fold in InstCombine.
Differential Revision: https://reviews.llvm.org/D34763
llvm-svn: 306980
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--> ~(a ^ b)
Summary:
I came across this while thinking about what would happen if one of the operands in this xor pattern was itself a inverted (A & ~B) ^ (~A & B)-> (A^B).
The patterns here assume that the (~a | ~b) will be demorganed to ~(a & b) first. Though I wonder if there's a multiple use case that would prevent the demorgan.
Reviewers: spatel
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34870
llvm-svn: 306967
|
| |
|
|
|
|
|
|
| |
cast. NFC
We aren't looking through any levels of IR here so I don't think we need the power of a matcher or the temporary variable it requires.
llvm-svn: 306885
|
| |
|
|
| |
llvm-svn: 306860
|
| |
|
|
| |
llvm-svn: 306815
|
| |
|
|
|
|
|
|
|
|
| |
match to the RHS match. No meaningful change intended.
There are two conditions ORed here with similar checks and each contain two matches that must be true for the if to succeed. With the commutable match on the first half of the OR then both ifs basically have the same first part and only the second part distinguishs. With this change we move the commutable match to second half and make the first half unique.
This caused some tests to change because we now produce a commuted result, but this shouldn't matter in practice.
llvm-svn: 306800
|
| |
|
|
| |
llvm-svn: 306781
|
| |
|
|
| |
llvm-svn: 306779
|
| |
|
|
|
|
| |
looking for all ones in Op1. This is consistent with 3 other not checks before this one. NFCI
llvm-svn: 306617
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As discussed on the mailing list it is legal to propagate TBAA to loads/stores
from/to smaller regions of a larger load tagged with TBAA. Do so for
(load->extractvalue)=>(gep->load) and similar foldings.
Reviewed By: sanjoy
Differential Revision: https://reviews.llvm.org/D31954
llvm-svn: 306615
|
| |
|
|
| |
llvm-svn: 306560
|