| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 320306
|
| |
|
|
|
|
| |
We just have to locally tag COPY as WriteMove
llvm-svn: 320304
|
| |
|
|
|
|
| |
We just have to locally tag COPY as WriteMove
llvm-svn: 320303
|
| |
|
|
| |
llvm-svn: 320302
|
| |
|
|
| |
llvm-svn: 320301
|
| |
|
|
|
|
| |
We just have to locally tag COPY as WriteMove
llvm-svn: 320300
|
| |
|
|
| |
llvm-svn: 320299
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CreateAddRecFromPHIWithCastsImpl() adds an IncrementNUSW overflow predicate
which allows the PSCEV rewriter to rewrite this scev expression:
(zext i8 {0, + , (trunc i32 step to i8)} to i32)
into
{0, +, (sext i8 (trunc i32 step to i8) to i32)}
But then it adds the wrong Equal predicate:
%step == (zext i8 (trunc i32 %step to i8) to i32).
instead of:
%step == (sext i8 (trunc i32 %step to i8) to i32)
This is fixed here.
Differential Revision: https://reviews.llvm.org/D40641
llvm-svn: 320298
|
| |
|
|
| |
llvm-svn: 320296
|
| |
|
|
|
|
|
|
| |
Z128 to Z256
Based on the fact that the 'Y' version of the instruction is next to this, I assume Z256 is the intended value.
llvm-svn: 320295
|
| |
|
|
|
|
| |
The VEX versions were present but not the legacy SSE versions.
llvm-svn: 320294
|
| |
|
|
|
|
| |
Sandybridge,Haswell,Broadwell,Skylake
llvm-svn: 320293
|
| |
|
|
|
|
| |
Sandy Bridge is also missing it, but it has other issues. See PR35590.
llvm-svn: 320292
|
| |
|
|
|
|
| |
Similar for all sizes of AND/OR/XOR/SUB/ADC/SBB/CMP.
llvm-svn: 320291
|
| |
|
|
|
|
| |
replacing an 'r'
llvm-svn: 320290
|
| |
|
|
|
|
| |
Somehow CMPSSrr/rm was there and the VEX version was there, but this was consistently missing.
llvm-svn: 320289
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds assembly & disassembly support for the e500mc "external pid"
instructions.
See https://reviews.llvm.org/D39249.
Patch by vit9696 <vit9696@avp.su>
llvm-svn: 320287
|
| |
|
|
| |
llvm-svn: 320285
|
| |
|
|
|
|
| |
they can only be selected by intrinsics.
llvm-svn: 320283
|
| |
|
|
|
|
| |
correct order relative to _Int
llvm-svn: 320282
|
| |
|
|
|
|
|
|
| |
This affects CVTSD2SS, FMA, RCP28, RSQRT28, and SQRT scalar instructions
'b' here refers to 'sae' not broadcast. These aren't memory instructions.
llvm-svn: 320281
|
| |
|
|
|
|
|
|
|
|
| |
should be outside of multicharacter parenthesized expressions
If the question mark is inside the parentheses it only applies to the single character proceeding it.
I had to make a few additional cleanups to fix some duplicate warnings that were exposed by fixing this.
llvm-svn: 320279
|
| |
|
|
| |
llvm-svn: 320278
|
| |
|
|
|
|
| |
sandybridge,haswell,broadwell,skylakeclient scheduler models.
llvm-svn: 320277
|
| |
|
|
| |
llvm-svn: 320276
|
| |
|
|
|
| |
Note: We may be too pessimistic here and should possibly use something closer to the LOCK arithmetic instructions
llvm-svn: 320275
|
| |
|
|
| |
llvm-svn: 320274
|
| |
|
|
| |
llvm-svn: 320273
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch improves performance on Cavium T99 as shown here (libquantum 0.2.4):
https://docs.google.com/spreadsheets/d/1Lo1o2E1NjrpkwS7DvYYWsiVvPdd93h7KBaqeptMrZPY/edit?usp=sharing
By increasing the LoopMicroOpsBufferSize in the Cavium T99 Scheduler file,
loop unrolling becomes more aggressive. This helps performance on T99.
Test case included.
Patch by Stefan Teleman
Differential Revision: https://reviews.llvm.org/D40695
llvm-svn: 320272
|
| |
|
|
|
|
| |
Don't assume that the pattern matched SRL can be cast to an Instruction (might be ConstExpr etc.)
llvm-svn: 320270
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are known
When the lowest bits of the operands to an integer multiply are known, the low bits of the result are deducible.
Code to deduce known-zero bottom bits already existed, but this change improves on that by deducing known-ones.
Patch by: Pedro Ferreira
Reviewers: craig.topper, sanjoy, efriedma
Differential Revision: https://reviews.llvm.org/D34029
llvm-svn: 320269
|
| |
|
|
| |
llvm-svn: 320268
|
| |
|
|
|
|
|
|
| |
(insert_subvector zero, vec, 0) for zeroing upper bits.
This can be better recognized during isel when the producer already zeroed the upper bits.
llvm-svn: 320267
|
| |
|
|
| |
llvm-svn: 320266
|
| |
|
|
| |
llvm-svn: 320265
|
| |
|
|
| |
llvm-svn: 320264
|
| |
|
|
| |
llvm-svn: 320263
|
| |
|
|
| |
llvm-svn: 320262
|
| |
|
|
| |
llvm-svn: 320261
|
| |
|
|
| |
llvm-svn: 320260
|
| |
|
|
| |
llvm-svn: 320257
|
| |
|
|
|
|
|
|
| |
NFCI.
Requires re-ordering of AVX512_maskable_custom arguments.
llvm-svn: 320255
|
| |
|
|
|
|
| |
NFCI.
llvm-svn: 320254
|
| |
|
|
| |
llvm-svn: 320253
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: aprantl, dblaikie, rnk
Reviewed By: rnk
Subscribers: eraman, llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D40432
llvm-svn: 320252
|
| |
|
|
|
|
|
|
|
|
| |
shift enough bits if we widened the vector.
We may need to widen the vector to make the shifts legal, but if we do that we need to make sure we shift left/right after accounting for the new size. If not we can't guarantee we are shifting in zeros.
The test cases affected actually show cases where we should move the shifts all together, but that's another problem.
llvm-svn: 320248
|
| |
|
|
|
|
| |
This reverts commit r320245.
llvm-svn: 320247
|
| |
|
|
|
|
| |
This reverts commit 57c16f9267969ebb09d6448607999b4a9f40c418.
llvm-svn: 320245
|
| |
|
|
|
|
|
|
| |
vector inputs.
We were previously using kunpck with zero inputs unnecessarily. And we had cases where we would insert into a zero vector and then insert into larger zero vector incurring two sets of shifts.
llvm-svn: 320244
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This relaxes an assertion inside SelectionDAGBuilder which is overly
restrictive on targets which have no concept of alignment (such as AVR).
In these architectures, all types are aligned to 8-bits.
After this, LLVM will only assert that accesses are aligned on targets
which actually require alignment.
This patch follows from a discussion on llvm-dev a few months ago
http://llvm.1065342.n5.nabble.com/llvm-dev-Unaligned-atomic-load-store-td112815.html
Reviewers: bogner, nemanjai, joerg, efriedma
Reviewed By: efriedma
Subscribers: efriedma, cactus, llvm-commits
Differential Revision: https://reviews.llvm.org/D39946
llvm-svn: 320243
|