| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
alive proofs:
a,b: https://rise4fun.com/Alive/4zsf
c,d,e,f: https://rise4fun.com/Alive/RC49
Indeed, not all of these patterns are canonical.
But since this fold will only produce a single instruction
i'm really interested in handling even uncanonical patterns.
Other than these 6 patterns, i can't think of any other
reasonable variants right now, although i'm sure they exist.
For now let's start with patterns where both shift amounts are variable,
with trivial constant "offset" between them, since i believe this is
both simplest to handle and i think this is most common.
But again, there are likely other variants where we could use
ValueTracking/ConstantRange to handle more cases.
https://bugs.llvm.org/show_bug.cgi?id=42563
llvm-svn: 365641
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Transform
pow(C,x)
To
exp2(log2(C)*x)
if C > 0, C != inf, C != NaN (and C is not power of 2, since we have some fold for such case already).
log(C) is folded by the compiler and exp2 is much faster to compute than pow.
Reviewers: spatel, efriedma, evandro
Reviewed By: evandro
Subscribers: lebedev.ri, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64099
llvm-svn: 365637
|
|
|
|
|
|
| |
Based on review comments for D64258.
llvm-svn: 365636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
one unique successor
Only instructions with two or more unique successors should be considered for unswitching.
Patch Author: Daniil Suchkov.
Reviewers: reames, asbirlea, skatkov
Reviewed By: skatkov
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D64404
llvm-svn: 365611
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test exposes a bug in SimpleLoopUnswitch that leads to a crash on
assert(SuccessorsCount > 1 && "Cannot unswitch a condition without multiple distinct successors!");
when SimpleLoopUnswitch considers unswitching of a loop by a switch with one successor.
Fix will be submitted soon.
Patch Author: Daniil Suchkov.
Reviewers: reames, asbirlea, skatkov
Reviewed By: skatkov
Subscribers: zzheng, llvm-commits
Differential Revision: https://reviews.llvm.org/D64403
llvm-svn: 365600
|
|
|
|
|
|
|
|
| |
I'm not sure if transforming any of these is valid as
a target-independent fold, but we might as well have
a few tests here to confirm or deny our position.
llvm-svn: 365523
|
|
|
|
| |
llvm-svn: 365506
|
|
|
|
| |
llvm-svn: 365501
|
|
|
|
| |
llvm-svn: 365495
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getMinSignedBits() > 64
APInt::getSExtValue will assert if getMinSignedBits() > 64. This can happen,
for instance, if examining an i128. Avoid this assertion by checking
Imm.getMinSignedBits() <= 64 before doing
getTLI()->isLegalAddImmediate(Imm.getSExtValue()). We could directly check
getMinSignedBits() <= 12 but it seems better to reuse the isLegalAddImmediate
helper for this.
Differential Revision: https://reviews.llvm.org/D64390
llvm-svn: 365462
|
|
|
|
|
|
| |
A while back, I added support for NE latches formed by LFTR. I didn't think that quite through, as LFTR will also produce the inverse EQ form for some loops and I hadn't handled that. This change just adds handling for that case as well.
llvm-svn: 365419
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Deduce the "returned" argument attribute by collecting all potentially
returned values.
Not only the unique return value, if any, can be used by subsequent
attributes but also the set of all potentially returned values as well
as the mapping from returned values to return instructions that they
originate from (see AAReturnedValues::checkForallReturnedValues).
Change in statistics (-stats) for LLVM-TS + Spec2006, totaling ~19% more "returned" arguments.
ADDED: attributor NumAttributesManifested n/a -> 637
ADDED: attributor NumAttributesValidFixpoint n/a -> 25545
ADDED: attributor NumFnArgumentReturned n/a -> 637
ADDED: attributor NumFnKnownReturns n/a -> 25545
ADDED: attributor NumFnUniqueReturned n/a -> 14118
CHANGED: deadargelim NumRetValsEliminated 470 -> 449 ( -4.468%)
REMOVED: functionattrs NumReturned 535 -> n/a
CHANGED: indvars NumElimIdentity 138 -> 164 ( +18.841%)
Reviewers: homerdin, hfinkel, fedor.sergeev, sanjoy, spatel, nlopes, nicholas, reames, efriedma, chandlerc
Subscribers: hiraditya, bollu, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D59919
llvm-svn: 365407
|
|
|
|
|
|
|
|
|
|
|
|
| |
Forming the canonical splat shuffle improves analysis and
may allow follow-on transforms (although some possibilities
are missing as shown in the test diffs).
The backend generically turns these patterns into build_vector,
so there should be no codegen regressions. All targets are
expected to be able to lower splats efficiently.
llvm-svn: 365379
|
|
|
|
| |
llvm-svn: 365362
|
|
|
|
|
|
|
|
|
|
|
| |
We recognize a splat from element 0 in (VectorUtils) llvm::getSplatValue()
and also in ShuffleVectorInst::isZeroEltSplatMask(), so this converts
to that form for better matching.
The backend generically turns these patterns into build_vector,
so there should be no codegen difference.
llvm-svn: 365342
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a function attribute, nofree, to indicate that a function does
not, directly or indirectly, call a memory-deallocation function (e.g., free,
C++'s operator delete).
Reviewers: jdoerfert
Differential Revision: https://reviews.llvm.org/D49165
llvm-svn: 365336
|
|
|
|
|
|
| |
I added this test in rL365325, but didn't mean to create an undef insert.
llvm-svn: 365333
|
|
|
|
| |
llvm-svn: 365325
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D63941
llvm-svn: 365324
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r365260 which broke the following tests:
Clang :: CodeGenCXX/cfi-mfcall.cpp
Clang :: CodeGenObjC/ubsan-nullability.m
LLVM :: Transforms/LoopVectorize/AArch64/pr36032.ll
llvm-svn: 365284
|
|
|
|
| |
llvm-svn: 365262
|
|
|
|
|
|
| |
Without this, we have the unfortunate property that tests are dependent on the order of operads passed the CreateOr and CreateAnd functions. In actual usage, we'd promptly optimize them away, but it made tests slightly more verbose than they should have been.
llvm-svn: 365260
|
|
|
|
| |
llvm-svn: 365227
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
insertelements
We allow forming a splat (broadcast) shuffle, but we were conservatively limiting
that to cases where all elements of the vector are specified. It should be safe
from a codegen perspective to allow undefined lanes of the vector because the
expansion of a splat shuffle would become the chain of inserts again.
Forming splat shuffles can reduce IR and help enable further IR transforms.
Motivating bugs:
https://bugs.llvm.org/show_bug.cgi?id=42174
https://bugs.llvm.org/show_bug.cgi?id=16739
Differential Revision: https://reviews.llvm.org/D63848
llvm-svn: 365147
|
|
|
|
| |
llvm-svn: 365141
|
|
|
|
|
|
|
| |
This fixes pr42492.
Differential Revision: https://reviews.llvm.org/D64124
llvm-svn: 365104
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the block being cloned contains a PHI node, in general, we need to
clone that PHI node, even though it's trivial. If the operand of the PHI
is an instruction in the block being cloned, the correct value for the
operand doesn't exist until SSAUpdater constructs it.
We usually don't hit this issue because we try to avoid threading across
loop headers, but it's possible to hit this in some cases involving
irreducible CFGs. I added a flag to allow threading across loop headers
to make the testcase easier to understand.
Thanks to Brian Rzycki for reducing the testcase.
Fixes https://bugs.llvm.org/show_bug.cgi?id=42085.
Differential Revision: https://reviews.llvm.org/D63913
llvm-svn: 365094
|
|
|
|
|
|
| |
As noted in the test change, this is not trivially NFC, but all of the changes in output are cases where the SCEVExpander form is more canonical/optimal than the hand generation.
llvm-svn: 365075
|
|
|
|
|
|
|
|
| |
The motivation for this is two fold:
1) Make the output (and thus tests) a bit more readable to a human trying to understand the result of the transform
2) Reduce spurious diffs in a potential future change to restructure all of this logic to use SCEVExpander (which hoists by default)
llvm-svn: 365066
|
|
|
|
|
|
| |
regress to in D62818
llvm-svn: 365056
|
|
|
|
|
|
|
|
| |
I'm not sure if this falls within the scope of SLP,
but we could create vector loads for some of these
patterns.
llvm-svn: 365055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I *think* we'd want this new variant, because we obviously
have better handling for `add` as compared to `sub`/`not`.
https://rise4fun.com/Alive/WMn
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]
Reviewers: spatel, nikic, huihuiz, efriedma
Reviewed By: spatel
Subscribers: RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63992
llvm-svn: 365011
|
|
|
|
|
|
|
|
|
|
|
| |
On some occasions ReuseOrCreateCast may convert previously
expanded value to undefined. That value may be passed by
SCEVExpander as an argument to InsertBinop making IV chain
undefined.
Differential revision: https://reviews.llvm.org/D63928
llvm-svn: 365009
|
|
|
|
|
|
|
|
| |
This reverts r364422 (git commit 1a3dc761860d620ac8ed7e32a4285952142f780b)
The inlining cost calculation is incorrect, leading to stack overflow due to large stack frames from heavy inlining.
llvm-svn: 365000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch introduces a new heuristic for guiding operand reordering. The new "look-ahead" heuristic can look beyond the immediate predecessors. This helps break ties when the immediate predecessors have identical opcodes (see lit test for an example).
Reviewers: RKSimon, ABataev, dtemirbulatov, Ayal, hfinkel, rnk
Reviewed By: RKSimon, dtemirbulatov
Subscribers: hiraditya, phosek, rnk, rcorcs, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60897
llvm-svn: 364964
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Partially solves https://bugs.llvm.org/show_bug.cgi?id=42190
Reviewers: spatel, nikic, efriedma
Reviewed By: efriedma
Subscribers: efriedma, nikic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63038
llvm-svn: 364940
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was actually wondering if there was some nicer way than m_Value()+cast,
but apparently what i was really "subconsciously" thinking about
was correctness issue.
hasNoUnsignedWrap()/hasNoUnsignedWrap() exist for Instruction,
not for BinaryOperator, so let's just use m_Instruction(),
thus both avoiding a cast, and a crash.
Fixes https://bugs.llvm.org/show_bug.cgi?id=42484,
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15587
llvm-svn: 364915
|
|
|
|
| |
llvm-svn: 364897
|
|
|
|
|
|
|
| |
https://bugs.llvm.org/show_bug.cgi?id=42456
https://rise4fun.com/Alive/Vf1p
llvm-svn: 364894
|
|
|
|
|
|
|
|
|
|
| |
Fixes verifier errors encountered in PR42413.
Reviewers: xur, t.p.northover, inglorion, gbiv, george.burgess.iv
Differential Revision: https://reviews.llvm.org/D63842
llvm-svn: 364861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use both one bit and signbit shifting to check for one bit merge.
Reviewers: lebedev.ri, spatel, efriedma, craig.topper
Reviewed By: lebedev.ri
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63903
llvm-svn: 364857
|
|
|
|
|
|
|
|
|
| |
Extends the transform from:
rL364341
...to include another (more common?) pattern that tests whether a
value is a power-of-2 (including or excluding zero).
llvm-svn: 364856
|
|
|
|
|
|
|
|
| |
This reverts r364478 (git commit 574cb0eb3a7ac95e62d223a60bef891171dfe321)
The patch is causing compilation timeouts.
llvm-svn: 364846
|
|
|
|
|
|
|
|
|
| |
(PR42466)
'and' is commutative, if we don't want to touch shift-of-const,
we still need to check the other hand of 'and'.
llvm-svn: 364844
|
|
|
|
|
|
|
| |
https://rise4fun.com/Alive/8O1
https://bugs.llvm.org/show_bug.cgi?id=42466
llvm-svn: 364824
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
To be noted, this pattern is not unhandled by instcombine per-se,
it is somehow does end up being folded when one runs opt -O3,
but not if it's just -instcombine. Regardless, that fold is
indirect, depends on some other folds, and is thus blind
when there are extra uses.
This does address the regression being exposed in D63992.
https://godbolt.org/z/7DGltU
https://rise4fun.com/Alive/EPO0
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=42459 | PR42459 ]]
Reviewers: spatel, nikic, huihuiz
Reviewed By: spatel
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63993
llvm-svn: 364792
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Given pattern:
`icmp eq/ne (and ((x shift Q), (y oppositeshift K))), 0`
we should move shifts to the same hand of 'and', i.e. rewrite as
`icmp eq/ne (and (x shift (Q+K)), y), 0` iff `(Q+K) u< bitwidth(x)`
It might be tempting to not restrict this to situations where we know
we'd fold two shifts together, but i'm not sure what rules should there be
to avoid endless combine loops.
We pick the same shift that was originally used to shift the variable we picked to shift:
https://rise4fun.com/Alive/6x1v
Should fix [[ https://bugs.llvm.org/show_bug.cgi?id=42399 | PR42399]].
Reviewers: spatel, nikic, RKSimon
Reviewed By: spatel
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63829
llvm-svn: 364791
|
|
|
|
|
|
|
|
|
|
|
|
| |
in bittest" pattern.
As discussed in https://reviews.llvm.org/D63829
*if* *both* shifts are one-use, we'd most likely want to produce `lshr`,
and not rely on ordering.
Also, there should likely be a *separate* fold to do this reordering.
llvm-svn: 364772
|
|
|
|
|
|
|
|
| |
fold (PR42459)
So we indeed to have this fold, but only if +1 is not the last operation..
llvm-svn: 364764
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To be noted, this pattern is not unhandled by instcombine per-se,
it is somehow does end up being folded when one runs opt -O3,
but not if it's just -instcombine. Regardless, that fold is
indirect, depends on some other folds, and is thus blind
when there are extra uses.
https://bugs.llvm.org/show_bug.cgi?id=42459
https://rise4fun.com/Alive/EPO0
llvm-svn: 364749
|