| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The outliner previously would never outline calls. Calls are pretty common in
files, so it makes sense to outline them. In fact, in the LLVM test suite, if
you count the number of instructions that the outliner misses when you outline
calls vs when you don't, it turns out that, on average, around 6% of the
instructions encountered are calls. So, if we outline calls, we can find more
candidates, and thus save some more space.
This commit adds that functionality and updates the mir test to reflect that.
llvm-svn: 320229
|
| |
|
|
|
|
| |
Both had a declaration of EmitXRayTable, but there is no method defined in either with that name. There is a emitXRayTable in the base class with a lower case 'e' and they both call that.
llvm-svn: 320213
|
| |
|
|
|
|
|
|
| |
to reflect the recently added features.
The name change is dicsussed in https://reviews.llvm.org/D38196
llvm-svn: 320204
|
| |
|
|
|
|
| |
is mentioned in the documentation (inserting a deref before the plus_uconst).
llvm-svn: 320203
|
| |
|
|
|
|
|
|
|
| |
varargs."
This puts the functionality under control of a command-line option which is
off by default to avoid breaking existing setups.
llvm-svn: 320197
|
| |
|
|
|
|
|
|
|
|
| |
signatures."
This includes a fix so that it doesn't transform declarations, and it
puts the functionality under control of a command-line option which is off
by default to avoid breaking existing setups.
llvm-svn: 320196
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Add gfx704
- Change bonaire to gfx704
- Remove gfx804
- Remove gfx901
- Remove gfx903
Differential Revision: https://reviews.llvm.org/D40046
llvm-svn: 320194
|
| |
|
|
|
|
| |
be lowered early
llvm-svn: 320193
|
| |
|
|
| |
llvm-svn: 320192
|
| |
|
|
|
|
|
|
|
|
|
|
| |
subvec, 0) for vector sizes that have native KSHIFT support.
For narrow sizes we'll widen the zero vector and widen the insert. Then do an extract_subvector to get back down to correct size.
This allows us to remove some patterns from the isel table that had to COPY_TO_REGCLASS to an oversized register, do the shift and then COPY_TO_REGCLASS back to the narrow register. Now this is represented explicitly in the DAG.
This seems to have perturbed the register allocation in one of the tests, but the number of instructions didn't change.
llvm-svn: 320190
|
| |
|
|
| |
llvm-svn: 320189
|
| |
|
|
| |
llvm-svn: 320188
|
| |
|
|
| |
llvm-svn: 320187
|
| |
|
|
|
|
|
|
| |
Follow up to r319705. Currently the MMO is
produced after this in the custom inserter,
so this doesn't change anything yet.
llvm-svn: 320186
|
| |
|
|
|
|
| |
Currently tagged these as system instructions.
llvm-svn: 320177
|
| |
|
|
|
|
|
|
| |
not available
Differential Revision: https://reviews.llvm.org/D40924
llvm-svn: 320176
|
| |
|
|
|
|
| |
Currently tagged these as system instructions, once we have uses for them (ASAN?) and they are faster we will need to improve on this.
llvm-svn: 320173
|
| |
|
|
|
|
|
|
| |
These are aliases, but the thing we're checking here is that the target has
vpsllv*, not that the data type is 256-bit. Those instructions exist for
128-bit vectors too...but sadly, not for all element sizes.
llvm-svn: 320170
|
| |
|
|
| |
llvm-svn: 320169
|
| |
|
|
|
|
| |
Put these under VecIMul itinerary classes for now - seems to be a good average value
llvm-svn: 320161
|
| |
|
|
| |
llvm-svn: 320159
|