Lexicographical comparison of SCEV trees is potentially expensive for big
expression trees. We can define ordering between them for AddRecs and
N-ary operations by SCEV NoWrap flags to make non-equality check
cheaper.
This change does not prevent grouping eqivalent SCEVs together and is
not supposed to have any meaningful impact on behavior of any transforms.
Reviewed By: sanjoy
Differential Revision: https://reviews.llvm.org/D40645
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319889 91177308-0d34-0410-b5e6-96231b3b80d8
Current implementation of `compareSCEVComplexity` is being unreasonable with `SCEVUnknown`s:
every time it sees one, it creates a new value cache and tries to prove equality of two values using it.
This cache reallocates and gets lost from SCEV to SCEV.
This patch changes this behavior: now we create one cache for all values and share it between SCEVs.
Reviewed By: sanjoy
Differential Revision: https://reviews.llvm.org/D40597
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319880 91177308-0d34-0410-b5e6-96231b3b80d8
Most of the code in these routines is for handling extends from vXi1 types. The 512-bit handling for other extends is very much like the AVX2 code. So make the special routines just do vXi1 types and move the other 512-bit handling to the place that handles AVX2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319878 91177308-0d34-0410-b5e6-96231b3b80d8
This caused PR35519.
> [memcpyopt] Teach memcpyopt to optimize across basic blocks
>
> This teaches memcpyopt to make a non-local memdep query when a local query
> indicates that the dependency is non-local. This notably allows it to
> eliminate many more llvm.memcpy calls in common Rust code, often by 20-30%.
>
> Fixes PR28958.
>
> Differential Revision: https://reviews.llvm.org/D38374
>
> [memcpyopt] Commit file missed in r319482.
>
> This change was meant to be included with r319482 but was accidentally
> omitted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319873 91177308-0d34-0410-b5e6-96231b3b80d8
Since the local hash is a different number of bytes depending
on host architecture, we don't have a consistent value. I
will need to re-do this test for both x86 and x64. For now
it accepts any value for the local hash.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319864 91177308-0d34-0410-b5e6-96231b3b80d8
Attempt to determine what the type will be legalized to and then analyze that to see if we will be able to use a vXi1 compare.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319861 91177308-0d34-0410-b5e6-96231b3b80d8
If the mask needs to be promoted that should occur by the legalizer detecting the mask operand needs to be promoted not as a side effect of another action.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319852 91177308-0d34-0410-b5e6-96231b3b80d8
If the mask needs to be promoted it should be handled by operand promotion after the result is legalized.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319851 91177308-0d34-0410-b5e6-96231b3b80d8
The mask will be promoted if necessary when operands are promoted. It's possible the mask type is legal, but the setcc result type is a different. We shouldn't promote to the setcc result type unless the mask needs to be promoted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319850 91177308-0d34-0410-b5e6-96231b3b80d8
GetWidenedVector does't guarantee the widened elements are zero which would break the intended behavior of the operation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319849 91177308-0d34-0410-b5e6-96231b3b80d8
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319840 91177308-0d34-0410-b5e6-96231b3b80d8
comparison of symbol names.
SymbolStringPool is a thread-safe string pool that will be used in upcoming Orc
APIs to facilitate efficient storage and fast comparison of symbol name strings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319839 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch allows to use derived pointers (GEPs/bitcasts) of unrelocated
base pointers. We care only about the uses of these derived pointers.
It is acheived by two changes:
1. When we have enough information to say if the pointer is unrelocated at some
point or not, we walk all BBs to remove from their Contributions all valid defs
of unrelocated pointers (GEP with unrelocated base or bitcast of unrelocated
pointer).
2. When it comes to verification we just ignore instructions that were removed
at stage 1.
Patch by Daniil Suchkov!
Reviewers: anna, reames, apilipenko, mkazantsev
Reviewed By: anna, mkazantsev
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40289
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319838 91177308-0d34-0410-b5e6-96231b3b80d8
NOTE: At the moment these use the WriteLoad/WriteStore classes, which severely underestimates the costs. This needs to be reviewed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319829 91177308-0d34-0410-b5e6-96231b3b80d8
This was only searching for explicit defs,
and asserting for any implicit or variadic
instruction defs, like inline asm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319826 91177308-0d34-0410-b5e6-96231b3b80d8
The patch originally broke Chromium (crbug.com/791714) due to its failing to
specify that the new pseudo instructions clobber EFLAGS. This commit fixes
that.
> Summary: This strengthens the guard and matches MSVC.
>
> Reviewers: hans, etienneb
>
> Subscribers: hiraditya, JDevlieghere, vlad.tsyrklevich, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D40622
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319824 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The aim is to make ModRefInfo checks and changes more intuitive
and less error prone using inline methods that abstract the bit operations.
Ideally ModRefInfo would become an enum class, but that change will require
a wider set of changes into FunctionModRefBehavior.
Reviewers: sanjoy, george.burgess.iv, dberlin, hfinkel
Subscribers: nlopes, llvm-commits
Differential Revision: https://reviews.llvm.org/D40749
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319821 91177308-0d34-0410-b5e6-96231b3b80d8
When folding a shift into a test-under-mask comparison, make sure that
there is no loss of precision when creating the shifted comparison
value. This usually never happens, except for certain always-true
comparisons in unoptimized code.
Fixes PR35529.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319818 91177308-0d34-0410-b5e6-96231b3b80d8
Surprisingly SIOptimizeExecMaskingPreRA can infinite loop
in some case with DBG_VALUE. Most tests using dbg_value are
run at -O0, so don't run this pass. This seems to only
happen when the value argument is undef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319808 91177308-0d34-0410-b5e6-96231b3b80d8
There's no such thing as a setcc with vector operands and scalar result. And if we're trying to widen the result we would have to already be looking at a vector result type.
So this patch renames the VSETCC function as the SETCC function and delete the original SETCC function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319799 91177308-0d34-0410-b5e6-96231b3b80d8
Use the .stack_pointer directive to implement WASM_STACK_POINTER for
specifying a global variable to be the stack pointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319797 91177308-0d34-0410-b5e6-96231b3b80d8
Max Kazantsev