This patch represents a condition with `Pred + LHS + RHS` in ReproducerEntry instead of `CmpInst + Not`.
It avoids creating temporary ICmpInsts in D155412.
Reviewed By: nikic, fhahn
Differential Revision: https://reviews.llvm.org/D155782
Currently we just bypass singleton phis, however we know that
in order to create the phi of ops all phis must be in the same block.
Therefore if one phi is a singleton then the rest are as well.
Differential Revision: https://reviews.llvm.org/D155478
These values don't propagate to the output; they are always replaced with a subsequent shuffle
or insertelement.
Tested equivalence with Alive2, e.g., https://alive2.llvm.org/ce/z/fj4s78.
Reading this code, I noticed that we call findMatInsertPt a lot, for the
same inputs. Calculate it once and save the result.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D155237
We pack this info in a tuple just to spread it back out for a function
call. Spreads in C++ are awkward. If I want to add an additional
element to the tuple, I need to add more calls to std::get<> later. Just
use a struct.
Reviewed By: void
Differential Revision: https://reviews.llvm.org/D155236
We have guarantees that induction variable will not overflow in the main
loop after the loop constrained. Therefore we can add no wrap flags on
its base in order not to miss info that loop is countable.
Add NSW flag now, since adding NUW flag requires a bit more complicated
analysis.
Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D154954
This reverts commit 36a6eb7d12a9f827bf3d5d4e5fdc68b8a62807b2.
[MemCpyOpt] check that load/store and dest/src alloca are all in the same bb
Differential Revision: https://reviews.llvm.org/D153453
Co-authored-by: serge-sans-paille <sguelton@mozilla.com>
D149348 did this for readnone calls, which are handled by SimpleValue.
This patch does the same for all other CSEable calls, which are handled
by CallValue.
Differential Revision: https://reviews.llvm.org/D153151
In CollectLoopInvariantFixupsAndFormulae(), LSR looks at users
outside the loop. E.g. if we have an addrec based on %base, and
%base is also used outside the loop, then we have to keep it in a
register anyway, which may make it more profitable to use
%base + %idx style addressing.
This reasoning doesn't hold up when the base is a constant, because
the constant can be rematerialized. The lsr-memcpy.ll test regressed
when enabling opaque pointers, because inttoptr (i64 6442450944 to ptr)
now also has a use outside the loop (previously it didn't due to a
pointer type difference), and that extra "use" results in worse use
of addressing modes in the loop. However, the use outside the loop
actually gets rematerialized, so the alleged register saving does
not occur.
The same reasoning also applies to other types of constants, such
as global variable references.
Differential Revision: https://reviews.llvm.org/D155073
Here is activated check elimination which was parsed previously in
https://reviews.llvm.org/D154069
* Added runtime check that computed range's boundary doesn't overflow in
terms of range type.
* From the statement INT_MIN <= END <= INT_MAX is inferred check:
isNonNegative(INT_MAX - END) * isNonNegative(END - INT_MIN).
* If overflow happens, check will return 0 and the safe interval will be
empty.
Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D154188
There is no need to print the entire function after a transform via
LLVM_DEBUG statements. These can be emulated via:
$ llc -print-after=consthoist -filter-print-funcs=<function name>
Otherwise, this makes the output of
$ llc -debug-only=consthoist
too verbose.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D154904
We may be able to replace the select with one of its select arms
at some but not all uses.
For uses in phi nodes this was already handled in the getValueOnEdge()
fold (which we can't drop entirely because it also handles an additional
case).
Fixes https://github.com/llvm/llvm-project/issues/63756.
Introduced the following range checks forms parsing:
* IV - Offset vs Limit
* Offset - IV vs Limit
Range's end boundary is computed as (Offset +/- Limit ).
If it's not possible to prove at compile time that computed upper bound
will not overflow, then scale boundary computation to a wider type to
perform overflow check at runtime.
Runtime overflow will be implemented in the next patch. In the meantime
safe range for such kind of checks isn't computed.
Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D154069
Partial progress towards removing in-tree uses of `getPointerTo()`,
by employing the following options:
* Drop the call entirely if the sole purpose of it is to support
a no-op bitcast (remove the no-op bitcast as well).
* Replace with `PointerType::get()`/`PointerType::getUnqual()`.
Also, remove no-op function `EmitBitCastOfLValueToProperType()`.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D154392
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
This is fixing all files missed in b0abd4893fa1.
Differential Revision: https://reviews.llvm.org/D154543
IRCE expects true edge of range check's branch comes to loop.
If it meets reverse case - invert the branch.
Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D148244
Next step of the preparatory refactoring for the upcoming support of new
new range check form to parse.
This change isolates logic of 'IV vs Limit' range check parsing to
simplify adding parsers for new range checks forms.
Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D154160
Next step of the preparatory refactoring for the upcoming support of
new range check form to parse.
Previous one: https://reviews.llvm.org/D154156
With this change we avoid meaningless parsing after realizing that Index
is not AddRec
Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D154158
Move the logic added in 3a57152d85e1 to normalizeForPostIncUse to catch
additional un-invertable cases. This fixes another mis-compile pointed
out by @peixin in D153004.
Preparatory refactoring for the upcoming support of new range check form
to parse.
With this change we always set Index and End values together in the same
place.
parseRangeCheckICmp specification updated.
Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D154156
Reassociation destroys nsw/nuw flags from BinOps that are changed. But if the
expression at the end of a tree that was altered, but didn't change itself,
the flags do not need to be removed. For example, if %a, %b and %c are
reassociated in
%x = add nsw i32 %a, %c
%y = add nsw i32 %x, %b
%z = add nsw i32 %y, %d
The value of %y and so add %y %d remains the same, and %z needn't drop the nsw
flags.
https://alive2.llvm.org/ce/z/_juAiV
Differential Revision: https://reviews.llvm.org/D154289
Simplification of non-equality predicates for solving constraint
systems is now supported by checking the validity of related
inequalities and equalities.
Differential Revision: https://reviews.llvm.org/D152684
Delegate checking of the constraint & its preconditions to the existing
::isValid. This reduces duplication and allows additional optimizations
together with D152730.
This patch extends the existing logic to handle cases where we have
branch conditions of the form (AND icmp, icmp) where the first icmp
implies the second. This can improve results in some cases, e.g. if
SimplifyCFG folded conditions from multiple branches to an AND.
The implementation handles this by adding a new type of check
(AndImpliedCheck), which are queued before conditional facts for the same
block.
When encountering AndImpliedChecks during solving, the first condition
is optimistically added to the constraint system, then we check if the
second icmp can be simplified, and finally the newly added entries are
removed.
The reason for doing things this way is to avoid clashes with signed
<-> unsigned condition transfer, which require us to re-order facts to
increase effectiveness.
Reviewed By: nikic, antoniofrighetto
Differential Revision: https://reviews.llvm.org/D151799
