| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Compute the strongly connected components of the CFG and fall back to
use these for blocks that are in loops that are not detected by
LoopInfo when computing loop back-edge and exit branch probabilities.
Reviewers: dexonsmith, davidxl
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D39385
llvm-svn: 317094
|
| |
|
|
|
|
| |
That change causes PR35103, so reverting until I figure it out.
llvm-svn: 317092
|
| |
|
|
| |
llvm-svn: 317091
|
| |
|
|
| |
llvm-svn: 317090
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch reverts rL311205 that was initially a wrong fix. The real problem
was in intersection of signed and unsigned ranges (see rL316552), and the
patch being reverted masked the problem instead of fixing it.
By now, the test against which rL311205 was made works OK even without this
code. This revert patch also contains a test case that demonstrates incorrect
behavior caused by rL311205: it is caused by incorrect choise of signed max
instead of unsigned.
llvm-svn: 317088
|
| |
|
|
|
|
| |
input. NFCI.
llvm-svn: 317087
|
| |
|
|
|
|
|
|
|
|
| |
So far we've only been using PACKSS truncations with 'all-bits or zero-bits' patterns (vector comparison results etc.). When really we can safely use it for any case as long as the number of sign bits reach down to the last 16-bits (or 8-bits if we're truncating to bytes).
The next steps after this is add the equivalent support for PACKUS and to support packing to sub-128 bit vectors for truncating stores etc.
Differential Revision: https://reviews.llvm.org/D39476
llvm-svn: 317086
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
By replacing branches to CommonExitBlock, we remove the node from
CommonExitBlock's predecessors, invalidating the iterator. The problem
is exposed when the common exit block has multiple predecessors and
needs to sink lifetime info. The modification in the test case trigger
the issue.
Reviewers: davidxl, davide, wmi
Reviewed By: davidxl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39112
llvm-svn: 317084
|
| |
|
|
|
|
|
|
|
|
|
|
| |
fmod specification requires the sign of the remainder is
the same as numerator in case remainder is zero.
Reviewers: gottesmm, scanon, arsenm, davide, craig.topper
Reviewed By: scanon
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D39225
llvm-svn: 317081
|
| |
|
|
|
|
|
|
|
|
| |
patterns so they don't get created with a v64i8 type.
Not sure why tablegen didn't error on this.
Fixes PR35158.
llvm-svn: 317079
|
| |
|
|
| |
llvm-svn: 317072
|
| |
|
|
| |
llvm-svn: 317059
|
| |
|
|
| |
llvm-svn: 317051
|
| |
|
|
|
|
|
|
| |
duplication [NFC]
This formulation might be slightly slower since I eagerly compute the cheap replacements. If anyone sees this having a compile time impact, let me know and I'll use lazy population instead.
llvm-svn: 317048
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39271
llvm-svn: 317046
|
| |
|
|
|
|
|
|
| |
Change the map key from DIFile* to the absolute path string. Computing
the absolute path isn't expensive because we already have a map that
caches the full path keyed on DIFile*.
llvm-svn: 317041
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Apps that benefit:
- alien isolation
- bioshock infinite
- civilization: beyond earth
- company of heroes 2
- dirt showdown
- dota 2
- F1 2015
- grid autosport
- hitman
- legend of grimrock
- serious sam 3: bfe
- shadow warrior
- talos principle
- total war: warhammer
- UE4 demos: effects cave, elemental, sun temple
Reviewers: arsenm, nhaehnle
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D38914
llvm-svn: 317038
|
| |
|
|
| |
llvm-svn: 317037
|
| |
|
|
|
|
|
|
| |
instead of splatting it."
GCC doesn't like it. This reverts commit r317028.
llvm-svn: 317030
|
| |
|
|
|
|
|
|
| |
of splatting it.
No functionality change intended.
llvm-svn: 317028
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 317027
|
| |
|
|
|
|
|
|
|
|
|
|
| |
SpeculativelyExecuteBB to prevent long names from being created
Currently the selects are created with the names of their inputs concatenated together. It's possible to get cases that chain these selects together resulting in long names due to multiple levels of concatenation. Our internal branch of llvm managed to generate names over 100000 characters in length on a particular test due to an extreme compounding of the names.
This patch changes the name to a generic name that is not dependent on its inputs.
Differential Revision: https://reviews.llvm.org/D39440
llvm-svn: 317024
|
| |
|
|
|
|
| |
This an intermediate state, the next patch will re-inline the markLoopInvariantPredicate function to reduce code duplication.
llvm-svn: 317016
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we call write(2) for each 32767 byte chunk. That is not
efficient because Linux can handle much larger write requests.
This patch changes the chunk size on Linux to 1 GiB.
This patch also changes the default chunks size to SSIZE_MAX. I think
that doesn't in practice change this function's behavior on any operating
system because SSIZE_MAX on 64-bit machine is unrealistically large,
and writing 2 GiB (SSIZE_MAX on 32-bit) on a 32-bit machine by a single
call of write(2) is also unrealistic, as the userspace is usually
limited to 2 GiB. That said, it is in general a good thing to do because
a write larger than SSIZE_MAX is implementation-defined in POSIX.
Differential Revision: https://reviews.llvm.org/D39444
llvm-svn: 317015
|
| |
|
|
|
|
| |
Possibly very slightly slower, but this code is not performance critical and the readability benefit alone is huge.
llvm-svn: 317012
|
| |
|
|
|
|
|
|
|
|
| |
It can't be a register prefix, anyway. This is consistent with the masm
docs on MSDN: https://msdn.microsoft.com/en-us/library/t4ax90d2.aspx
This is a straight-forward extension of our support for "MOD"
implemented in https://reviews.llvm.org/D33876 / r306425
llvm-svn: 317011
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fixes a bunch of assert-on-invalid-bitcode regressions after 315483.
Expected<> calls assertIsChecked() in its dtor, and operator bool() only calls
setChecked() if there's no error. So for functions that don't return an error
itself, the Expected<> version needs explicit code to disarm the error that the
ErrorOr<> code didn't need.
https://reviews.llvm.org/D39437
llvm-svn: 317010
|
| |
|
|
|
|
|
| |
COFF comdats require symbol table entries, which means the comdat leader
cannot have private linkage.
llvm-svn: 317009
|
| |
|
|
|
|
|
|
| |
computeKnownBits/ComputeNumSignBits
Mainly a perf improvements as most combines will have occurred before we lower to these instructions
llvm-svn: 317005
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 317003
|
| |
|
|
|
|
|
|
|
|
| |
If a select instruction tests the returned flag of a cmpxchg instruction and
selects between the returned value of the cmpxchg instruction and its compare
operand, the result of the select will always be equal to its false value.
Differential Revision: https://reviews.llvm.org/D39383
llvm-svn: 316994
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The optimisation remarks for loop unrolling with an unrolled remainder looks something like:
test.c:7:18: remark: completely unrolled loop with 3 iterations [-Rpass=loop-unroll]
C[i] += A[i*N+j];
^
test.c:6:9: remark: unrolled loop by a factor of 4 with run-time trip count [-Rpass=loop-unroll]
for(int j = 0; j < N; j++)
^
This removes the first of the two messages.
Differential revision: https://reviews.llvm.org/D38725
llvm-svn: 316986
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
extract subvector of vXi1 from vYi1 is poorly supported by LLVM and most of the time end with an assertion.
This patch fixes this issue by adding new patterns to the TD file.
Reviewers:
1. guyblank
2. igorb
3. zvi
4. ayman
5. craig.topper
Differential Revision: https://reviews.llvm.org/D39292
Change-Id: Ideb4d7e946c8d40cfce2920891f2d89fe64c58f8
llvm-svn: 316981
|
| |
|
|
|
|
|
| |
The address can be presented as a bitcast of baseReg.
In this case it is still trivial but OriginalValue != baseReg.
llvm-svn: 316980
|
| |
|
|
|
|
|
|
|
|
| |
Rename `Offset`, `Scale`, `Length` into `Begin`, `Step`, `End` respectively
to make naming of similar entities for Ranges and Range Checks more
consistent.
Differential Revision: https://reviews.llvm.org/D39414
llvm-svn: 316979
|
| |
|
|
|
|
|
|
|
|
| |
enabled. Use 128-bit VLX instruction when VLX is enabled.
Unfortunately, this weakens our ability to do domain fixing when AVX512DQ is not enabled, but it is consistent with our 256-bit behavior.
Maybe we should add custom handling to domain fixing to allow EVEX integer XOR/AND/OR/ANDN to switch to VEX encoded fp instructions if the high registers aren't being used?
llvm-svn: 316978
|
| |
|
|
| |
llvm-svn: 316977
|
| |
|
|
|
|
|
|
| |
As noted in the nice block comment, the previous code didn't actually handle multi-entry loops correctly, it just assumed SCEV didn't analyze such loops. Given SCEV has comments to the contrary, that seems a bit suspect. More importantly, the pass actually requires loopsimplify form which ensures a loop-preheader is available. Remove the excessive generaility and shorten the code greatly.
Note that we do successfully analyze many multi-entry loops, but we do so by converting them to single entry loops. See the added test case.
llvm-svn: 316976
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pass control flow to successors"
This patch fixes the miscompile that happens when PRE hoists loads across guards and
other instructions that don't always pass control flow to their successors. PRE is now prohibited
to hoist across such instructions because there is no guarantee that the load standing after such
instruction is still valid before such instruction. For example, a load from under a guard may be
invalid before the guard in the following case:
int array[LEN];
...
guard(0 <= index && index < LEN);
use(array[index]);
Differential Revision: https://reviews.llvm.org/D37460
llvm-svn: 316975
|
| |
|
|
|
|
|
|
| |
Previously, the code returned early from the *function* when it couldn't find a free expansion, it should be returning from the *transform*. I don't have a test case, noticed this via inspection.
As a follow up, I'm going to revisit the logic in the extract function. I think that essentially the whole helper routine can be replaced with SCEVExpander, but I wanted to do that in a series of separate commits.
llvm-svn: 316974
|
| |
|
|
| |
llvm-svn: 316973
|
| |
|
|
|
|
| |
These files shouldn't have been submitted in 316967
llvm-svn: 316968
|
| |
|
|
|
|
|
|
| |
Issue found by llvm-isel-fuzzer on OSS fuzz, https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3725
If anyone actually cares about > 64 bit arithmetic, there's a lot more to do in this area. There's a bunch of obviously wrong code in the same function. I don't have the time to fix all of them and am just using this to understand what the workflow for fixing fuzzer cases might look like.
llvm-svn: 316967
|
| |
|
|
| |
llvm-svn: 316964
|
| |
|
|
|
|
| |
We don't need to extend/truncate the Known structure before calling computeKnownBits - it will reset at the start of the function.
llvm-svn: 316962
|
| |
|
|
| |
llvm-svn: 316960
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
InferAddressSpaces assumes the pointee type of addrspacecast
is the same as the operand, which is not always true and causes
invalid IR.
This bug cause build failure in HCC.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D39432
llvm-svn: 316957
|
| |
|
|
| |
llvm-svn: 316955
|
| |
|
|
|
|
|
|
| |
It's not guaranteed. There's a bug open to sort them in predecessor
order, but it won't happen anytime soon. In the meanwhile, passes
will have to do an O(#preds) scan. Such is life.
llvm-svn: 316953
|
| |
|
|
|
|
|
|
|
|
| |
Revert r316478.
A test case has failed.
Will recommit this change once we find and fix the failure.
This reverts commit 7c330fabaedaba3d02c58bc3cc1198896c895f34.
llvm-svn: 316952
|