| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 319880
|
|
|
|
|
|
|
|
| |
LowerZERO_EXTEND_AVX512/LowerSIGN_EXTEND_AVX512. NFCI
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.
llvm-svn: 319878
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
basic blocks"
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.
llvm-svn: 319873
|
|
|
|
| |
llvm-svn: 319870
|
|
|
|
|
|
|
| |
This reverts commit r319773. It was causing some buildbots to hang, e.g.
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/builds/5589
llvm-svn: 319867
|
|
|
|
|
|
| |
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.
llvm-svn: 319861
|
|
|
|
| |
llvm-svn: 319859
|
|
|
|
| |
llvm-svn: 319855
|
|
|
|
|
|
|
|
|
| |
Currently nothing uses this, but this at least gets the core
algorithm in, and adds some test to demonstrate correctness.
Differential Revision: https://reviews.llvm.org/D40736
llvm-svn: 319854
|
|
|
|
|
|
|
|
| |
the result.
The condition operand should be promoted during operand promotion.
llvm-svn: 319853
|
|
|
|
|
|
| |
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.
llvm-svn: 319852
|
|
|
|
|
|
| |
If the mask needs to be promoted it should be handled by operand promotion after the result is legalized.
llvm-svn: 319851
|
|
|
|
|
|
|
|
| |
result type while widening the result. Just widen the mask.
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.
llvm-svn: 319850
|
|
|
|
|
|
| |
GetWidenedVector does't guarantee the widened elements are zero which would break the intended behavior of the operation.
llvm-svn: 319849
|
|
|
|
|
|
| |
leak problem
llvm-svn: 319841
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 319838
|
|
|
|
|
|
|
|
|
|
| |
As suggested by Eli Friedman, instead of aborting if an overflow check
uses something other than SETEQ or SETNE, simply do not apply the
optimization.
Differential Revision: https://reviews.llvm.org/D39147
llvm-svn: 319837
|
|
|
|
| |
llvm-svn: 319833
|
|
|
|
| |
llvm-svn: 319831
|
|
|
|
|
| |
NOTE: At the moment these use the WriteLoad/WriteStore classes, which severely underestimates the costs. This needs to be reviewed.
llvm-svn: 319829
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40741
llvm-svn: 319827
|
|
|
|
|
|
|
|
| |
This was only searching for explicit defs,
and asserting for any implicit or variadic
instruction defs, like inline asm.
llvm-svn: 319826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
protecting the stack"
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
llvm-svn: 319824
|
|
|
|
| |
llvm-svn: 319822
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 319821
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 319818
|
|
|
|
| |
llvm-svn: 319815
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not currently valid by the wasm spec, however:
- It replaces doing set_global on an immutable global, which is also
not valid.
- It's expected be valid in the near future:
https://github.com/WebAssembly/threads/blob/master/proposals/threads/Globals.md
- This only occurs before linking, so a fully linked object will be
valid.
llvm-svn: 319810
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 319808
|
|
|
|
|
|
|
|
| |
This uses ConstantRange::makeGuaranteedNoWrapRegion's newly-added handling for subtraction to allow CVP to remove some subtraction overflow checks.
Differential Revision: https://reviews.llvm.org/D40039
llvm-svn: 319807
|
|
|
|
|
|
|
|
| |
Previously ConstantRange::makeGuaranteedNoWrapRegion only handled addition. This adds support for subtraction.
Differential Revision: https://reviews.llvm.org/D40036
llvm-svn: 319806
|
|
|
|
| |
llvm-svn: 319804
|
|
|
|
|
|
| |
I removed a space at the end of a comment. NFC.
llvm-svn: 319803
|
|
|
|
|
|
|
|
|
|
| |
from vector widening.
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.
llvm-svn: 319799
|
|
|
|
|
|
| |
The method implementation was removed in r318982.
llvm-svn: 319798
|
|
|
|
|
|
|
| |
Use the .stack_pointer directive to implement WASM_STACK_POINTER for
specifying a global variable to be the stack pointer.
llvm-svn: 319797
|
|
|
|
|
|
|
| |
.import_global is used by the ELF-based target and not needed by the wasm
target.
llvm-svn: 319796
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D40702
llvm-svn: 319794
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this when lld failed to replace the output file it would leave
the temporary behind. The problem is that the existing logic is
- cancel the delete flag
- rename
We have to cancel first to avoid renaming and then crashing and
deleting the old version. What is missing then is deleting the
temporary file if the rename fails.
This can be an issue on both unix and windows, but I am not sure how
to cause the rename to fail reliably on unix. I think it can be done
on ZFS since it has an ACL system similar to what windows uses, but
adding support for checking that in llvm-lit is probably not worth it.
llvm-svn: 319786
|
|
|
|
| |
llvm-svn: 319784
|
|
|
|
|
|
| |
more
llvm-svn: 319782
|
|
|
|
|
|
|
|
|
| |
This patch, together with a matching clang patch (https://reviews.llvm.org/D39719), implements the lowering of X86 kunpack intrinsics to IR.
Differential Revision: https://reviews.llvm.org/D39720
Change-Id: I4088d9428478f9457f6afddc90bd3d66b3daf0a1
llvm-svn: 319778
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Search from AND nodes to find whether they can be propagated back to
loads, so that the AND and load can be combined into a narrow load.
We search through OR, XOR and other AND nodes and all bar one of the
leaves are required to be loads or constants. The exception node then
needs to be masked off meaning that the 'and' isn't removed, but the
loads(s) are narrowed still.
Differential Revision: https://reviews.llvm.org/D39604
llvm-svn: 319773
|
|
|
|
| |
llvm-svn: 319772
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Found out, at code inspection, that there was a fault in
DAGCombiner::CombineConsecutiveLoads for big-endian targets.
A BUILD_PAIR is always having the least significant bits of
the composite value in element 0. So when we are doing the checks
for consecutive loads, for big endian targets, we should check
if the load to elt 1 is at the lower address and the load
to elt 0 is at the higher address.
Normally this bug only resulted in missed oppurtunities for
doing the load combine. I guess that in some rare situation it
could lead to faulty combines, but I've not seen that happen.
Note that this patch actually will trigger load combine for
some big endian regression tests.
One example is test/CodeGen/PowerPC/anon_aggr.ll where we now get
t76: i64,ch = load<LD8[FixedStack-9]
instead of
t37: i32,ch = load<LD4[FixedStack-10]>
t35: i32,ch = load<LD4[FixedStack-9]>
t41: i64 = build_pair t37, t35
before legalization. Then the legalization will split the LD8
into two loads, so the end result is the same. That should
verify that the transfomation is correct now.
Reviewers: niravd, hfinkel
Reviewed By: niravd
Subscribers: nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D40444
llvm-svn: 319771
|
|
|
|
| |
llvm-svn: 319770
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A true or false result is expected from a comparison, but it seems the possibility of undef was overlooked, which could lead to a failed assert. This is fixed by this patch by bailing out if we encounter undef.
The bug is old and the assert has been there since the end of 2014, so it seems this is unusual enough to forego optimization.
Patch by JesperAntonsson.
Reviewers: spatel, eeckstein, hans
Reviewed By: hans
Subscribers: uabelho, llvm-commits
Differential Revision: https://reviews.llvm.org/D40639
llvm-svn: 319768
|
|
|
|
| |
llvm-svn: 319767
|
|
|
|
|
|
|
|
|
| |
Pull the checks upon the load out from ReduceLoadWidth into their own
function.
Differential Revision: https://reviews.llvm.org/D40833
llvm-svn: 319766
|
|
|
|
| |
llvm-svn: 319765
|