| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
folding phis
Summary:
When we fold vector constants that are operands of phi's that feed into select,
we need to set the correct insertion point for the *new* selects that get generated.
The correct insertion point is the incoming block for the phi.
Such cases can occur with patch r298845, which fixed folding of
vector constants, but the new selects could be inserted incorrectly (as the added
test case shows).
Reviewers: majnemer, spatel, sanjoy
Reviewed by: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34162
llvm-svn: 305591
|
| |
|
|
|
|
| |
conservative single use checks. NFC
llvm-svn: 305562
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Background: http://lists.llvm.org/pipermail/llvm-dev/2017-May/112779.html
This change is to alter the prototype for the atomic memcpy intrinsic. The prototype itself is being changed to more closely resemble the semantics and parameters of the llvm.memcpy intrinsic -- to ease later combination of the llvm.memcpy and atomic memcpy intrinsics. Furthermore, the name of the atomic memcpy intrinsic is being changed to make it clear that it is not a generic atomic memcpy, but specifically a memcpy is unordered atomic.
Reviewers: reames, sanjoy, efriedma
Reviewed By: reames
Subscribers: mzolotukhin, anna, llvm-commits, skatkov
Differential Revision: https://reviews.llvm.org/D33240
llvm-svn: 305558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
== (K1 | K2) if K1 and K2 are a 1-bit mask
Summary: This is the demorganed version of the case we already handle for the OR of iszero.
Reviewers: spatel
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34244
llvm-svn: 305548
|
| |
|
|
|
|
| |
instruction count when trying to fold (select (icmp eq (and X, C1), 0), Y, (or Y, C2))->(or (shl (and X, C1), C3), y) when the pieces have multiple uses.
llvm-svn: 305509
|
| |
|
|
| |
llvm-svn: 305492
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(K1 | K2) when the one of the Ands is commuted relative to the other
Currently we expect A to be on the same side in both Ands but nothing guarantees that.
While there also switch to using matchers for some of the code.
Differential Revision: https://reviews.llvm.org/D34230
llvm-svn: 305487
|
| |
|
|
| |
llvm-svn: 305474
|
| |
|
|
|
|
| |
commuted IR. NFC
llvm-svn: 305438
|
| |
|
|
|
|
|
|
|
|
|
|
| |
with non power of 2 bit widths
There's an early out that's trying to detect when we don't know any bits that make up the legal range of a shift. The code subtracts one from BitWidth which creates a mask in the lower bits for power of 2 bit widths. This is then ANDed with the known bits to see if any of those bits are known. If the bit width isn't a power of 2 this creates a non-sensical mask.
This patch corrects this by rounding up to a power of 2 before doing the subtract and mask.
Differential Revision: https://reviews.llvm.org/D34165
llvm-svn: 305400
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things.
The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack.
This is done in three stages:
• The first patch (LLVM) adds support for DW_OP_plus_uconst.
• The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst.
• The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions.
Patch by Sander de Smalen.
Reviewers: echristo, pcc, aprantl
Reviewed By: aprantl
Subscribers: fhahn, javed.absar, aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D33894
llvm-svn: 305386
|
| |
|
|
|
|
|
|
| |
eq (and X, C1), 0), Y, (or Y, C2)) when the icmp portion gets turned into a truncate and a signed compare with 0.
InstCombine has an optimization that recognizes an and with the sign bit of legal type size and turns it into a truncate and compare that checks the sign bit. But the select handling code doesn't recognize this idiom.
llvm-svn: 305338
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to https://reviews.llvm.org/D33879 / https://reviews.llvm.org/rL304939 ,
and was discussed in https://reviews.llvm.org/D33338.
We prefer this form because a narrower shift may be cheaper, and we can more easily fold a
zext than a sext.
http://rise4fun.com/Alive/slVe
Name: shz
%s = sext i8 %x to i12
%r = lshr i12 %s, 4
=>
%a = ashr i8 %x, 4
%r = zext i8 %a to i12
llvm-svn: 305190
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D33737
llvm-svn: 305132
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was discussed in D33338. We have larger pattern-matching ending in a truncate that
we can reduce or remove by handling these smaller patterns first. Further motivation is
that narrower shift ops are easier for value tracking and zext is better than sext.
http://rise4fun.com/Alive/rhh
Name: boolshift
%sext = sext i1 %x to i8
%r = lshr i8 %sext, 7
=>
%r = zext i1 %x to i8
Name: noboolshift
%sext = sext i3 %x to i8
%r = lshr i8 %sext, 7
=>
%sh = lshr i3 %x, 2
%r = zext i3 %sh to i8
Differential Revision: https://reviews.llvm.org/D33879
llvm-svn: 304939
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug that can cause extractelements with operands that
haven't been defined yet to be inserted at a wrong point when
optimising insertelements.
Patch by Karl Hylen.
Differential Revision: https://reviews.llvm.org/D33449
llvm-svn: 304701
|
| |
|
|
|
|
| |
known bits.
llvm-svn: 304669
|
| |
|
|
|
|
| |
to understand that the second argument is still a scalar.
llvm-svn: 304668
|
| |
|
|
|
|
| |
some showing missed optimizations. NFC
llvm-svn: 304667
|
| |
|
|
|
|
| |
like a copy paste mistake.
llvm-svn: 304666
|
| |
|
|
|
|
| |
constant
llvm-svn: 304562
|
| |
|
|
|
|
|
| |
The existing test was not minimal, and there was no coverage
for the variants with a constant or vector types.
llvm-svn: 304555
|
| |
|
|
|
|
| |
instructions after cttz/ctlz/ctpop where some bits of the input is known.
llvm-svn: 304224
|
| |
|
|
|
|
|
|
| |
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D28565
llvm-svn: 303870
|
| |
|
|
|
|
|
|
|
|
|
| |
There's probably a lot more like this (see also comments in D33338 about responsibility),
but I suspect we don't usually get a visible manifestation.
Given the recent interest in improving InstCombine efficiency, another potential micro-opt
that could be repeated several times in this function: morph the existing icmp pred/operands
instead of creating a new instruction.
llvm-svn: 303860
|
| |
|
|
|
|
|
|
|
| |
The swapped operands in the first test is a manifestation of an
inefficiency for vectors that doesn't exist for scalars because
the IRBuilder checks for an all-ones mask for scalars, but not
vectors.
llvm-svn: 303818
|
| |
|
|
| |
llvm-svn: 303816
|
| |
|
|
| |
llvm-svn: 303808
|
| |
|
|
|
|
|
|
|
| |
As noted in https://bugs.llvm.org/show_bug.cgi?id=33138 and
the comments, there are multiple ways to view this. If we
choose not to solve this in InstCombine, these tests will
serve as documentation of that choice.
llvm-svn: 303755
|
| |
|
|
|
|
|
|
| |
The solution for PR26702 ( https://bugs.llvm.org/show_bug.cgi?id=26702 )
added a canonicalization rule, but the minimal regression tests don't
demonstrate how that rule interacts with other folds.
llvm-svn: 303750
|
| |
|
|
| |
llvm-svn: 303663
|
| |
|
|
|
|
|
|
|
| |
This fixes the first part of:
https://bugs.llvm.org/show_bug.cgi?id=33138
More work is needed for the bitcasted variant.
llvm-svn: 303660
|
| |
|
|
| |
llvm-svn: 303659
|
| |
|
|
|
|
|
|
|
|
| |
Also, rename the tests and the file, add comments, and add more tests
because there are no existing tests for some of these folds.
These patterns are particularly important for crippled vector ISAs that
have limited compare predicates (PR33138).
llvm-svn: 303652
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we end up miscompiling, transforming:
define i8 @tinky() {
%sext = sext i1 1 to i16
%hibit = lshr i16 %sext, 15
%tr = trunc i16 %hibit to i8
ret i8 %tr
}
into:
%sext = sext i1 1 to i8
ret i8 %sext
and the first get folded to ret i8 1, while the second gets folded
to ret i8 -1.
Eventually we should get rid of this transform entirely, but for now,
this at least fixes a know correctness bug.
Differential Revision: https://reviews.llvm.org/D33338
llvm-svn: 303513
|
| |
|
|
|
|
|
|
|
| |
As discussed in:
https://reviews.llvm.org/D33338
...we may be able to remove a wider pattern match by doing these more
basic canonicalizations.
llvm-svn: 303504
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the strlen optimization code to work for both strlen and wcslen.
This especially helps with programs in the wild where people pass
L"string"s to const std::wstring& function parameters and the wstring
constructor gets inlined.
This also fixes a lingerind API problem/bug in getConstantStringInfo()
where zeroinitializers would always give you an empty string (without a
length) back regardless of the actual length of the initializer which
did not work well in the TrimAtNul==false causing the PR mentioned
below.
Note that the fixed getConstantStringInfo() needed fixes to SelectionDAG
memcpy lowering and may lead to some cases for out-of-bounds
zeroinitializer accesses not getting optimized anymore. So some code
with UB may produce out of bound memory reads now instead of just
producing zeros.
The refactoring "accidentally" fixes http://llvm.org/PR32124
Differential Revision: https://reviews.llvm.org/D32839
llvm-svn: 303461
|
| |
|
|
|
|
| |
Clarify a comment while I'm here.
llvm-svn: 303447
|
| |
|
|
| |
llvm-svn: 303445
|
| |
|
|
| |
llvm-svn: 303387
|
| |
|
|
|
|
| |
Previously, this test was checking for 'or i1', but that was actually matched by 'xor i1'.
llvm-svn: 303364
|
| |
|
|
| |
llvm-svn: 303319
|
| |
|
|
|
|
| |
This is another form of the problem discussed in D32143.
llvm-svn: 303315
|
| |
|
|
|
|
|
|
|
|
|
| |
The missing optimization for xor-of-icmps still needs to be added, but by
being more efficient (not generating unnecessary logic ops with constants)
we avoid the bug.
See discussion in post-commit comments:
https://reviews.llvm.org/D32143
llvm-svn: 303312
|
| |
|
|
| |
llvm-svn: 303310
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There should be a slight efficiency improvement from handling icmp/fcmp with one matcher and reducing duplicated code.
The larger motivation is that there are questions about how predicate canonicalization is handled, and the refactoring
should make it easier if we want to change any of that behavior.
1. As noted in the code comment, we've chosen 3 of the 16 FCMP preds as not canonical. Why those 3? It goes back to
rL32751 from what I can tell, but I'm not sure if there's a justification for that rule.
2. We currently do not canonicalize integer select conditions. Should we use the same rule that applies to branches
for selects?
3. We currently do canonicalize some FP select conditions, and those rules would conflict with the rule shown here.
Should one or both be changed?
No-functional-change-intended, but adding tests anyway because there's no coverage for most of the predicates.
Differential Revision: https://reviews.llvm.org/D33247
llvm-svn: 303261
|
| |
|
|
| |
llvm-svn: 303216
|
| |
|
|
| |
llvm-svn: 303203
|
| |
|
|
|
|
| |
@llvm.dbg.* calls in visitCallInst(). They can be safely ignored.
llvm-svn: 303202
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The referenced tests are derived from:
https://bugs.llvm.org/show_bug.cgi?id=32791
and:
https://reviews.llvm.org/D33172
The motivation for including negative tests may not be clear, so I'm adding an explanatory comment here.
In the post-commit thread for r303133:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170515/453793.html
...it was mentioned that we don't want to add redundant tests. This is a valid point. But in this case,
we have a patch under review (D33172) that demonstrates that no existing regression tests are affected by
a proposed code change, but these are. Therefore, I think these tests have value not visible in any
existing regression tests regardless of whether they show a transform.
Differential Revision: https://reviews.llvm.org/D33242
llvm-svn: 303185
|