| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit allows matchSelectPattern to recognize clamp of float
arguments in the presence of FMF the same way as already done for
integers.
This case is a little different though. With integers, given the
min/max pattern is recognized, DAGBuilder starts selecting MIN/MAX
"automatically". That is not the case for float, because for them only
full FMINNAN/FMINNUM/FMAXNAN/FMAXNUM ISD nodes exist and they do care
about NaNs. On the other hand, some backends (e.g. X86) have only
FMIN/FMAX nodes that do not care about NaNS and the former NAN/NUM
nodes are illegal thus selection is not happening. So I decided to do
such kind of transformation in IR (InstCombiner) instead of
complicating the logic in the backend.
Reviewers: spatel, jmolloy, majnemer, efriedma, craig.topper
Reviewed By: efriedma
Subscribers: hiraditya, javed.absar, n.bozhenov, llvm-commits
Patch by Andrei Elovikov <andrei.elovikov@intel.com>
Differential Revision: https://reviews.llvm.org/D33186
llvm-svn: 306525
|
|
|
|
|
|
|
|
|
|
|
|
| |
the constant is a vector splat or the scalar bit width is larger than 64-bits
The check to see if we can propagate the nsw flag used m_ConstantInt(uint64_t*&) which doesn't work with splat vectors and has a restriction that the bitwidth of the ConstantInt must be 64-bits are less.
This patch changes it to use m_APInt to remove both these issues
Differential Revision: https://reviews.llvm.org/D34699
llvm-svn: 306457
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This canonicalization was suggested in D33172 as a way to make InstCombine behavior more uniform.
We have this transform for icmp+br, so unless there's some reason that icmp+select should be
treated differently, we should do the same thing here.
The benefit comes from increasing the chances of creating identical instructions. This is shown in
the tests in logical-select.ll (PR32791). InstCombine doesn't fold those directly, but EarlyCSE
can simplify the identical cmps, and then InstCombine can fold the selects together.
The possible regression for the tests in select.ll raises questions about poison/undef:
http://lists.llvm.org/pipermail/llvm-dev/2017-May/113261.html
...but that transform is just as likely to be triggered by this canonicalization as it is to be
missed, so we're just pointing out a commutation deficiency in the pattern matching:
https://reviews.llvm.org/rL228409
Differential Revision: https://reviews.llvm.org/D34242
llvm-svn: 306435
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
metadata out of InstCombine and into helpers.
NFC, this just exposes the logic used by InstCombine when propagating
metadata from one load instruction to another. The plan is to use this
in SROA to address PR32902.
If anyone has better ideas about how to factor this or name variables,
I'm all ears, but this seemed like a pretty good start and lets us make
progress on the PR.
This is based on a patch by Ariel Ben-Yehuda (D34285).
llvm-svn: 306267
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://rise4fun.com/Alive/i8Q
A narrow bitwise logic op is obviously better than math for value tracking,
and zext is better than sext. Typically, the 'not' will be folded into an
icmp predicate.
The IR difference would even survive through codegen for x86, so we would see
worse code:
https://godbolt.org/g/C14HMF
one_or_zero(int, int): # @one_or_zero(int, int)
xorl %eax, %eax
cmpl %esi, %edi
setle %al
retq
one_or_zero_alt(int, int): # @one_or_zero_alt(int, int)
xorl %ecx, %ecx
cmpl %esi, %edi
setg %cl
movl $1, %eax
subl %ecx, %eax
retq
llvm-svn: 306243
|
|
|
|
| |
llvm-svn: 306205
|