| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
This patch adds tablegen patterns to select F16C float-to-half-float
conversion instructions from 'f32_to_f16' and 'f16_to_f32' dag nodes.
If the target doesn't have F16C, then 'f32_to_f16' and 'f16_to_f32'
are expanded into library calls.
llvm-svn: 212293
|
| |
|
|
|
|
|
| |
Adds support for __builtin_arm_isb. Also corrects DSB and ISB instructions
modelling by adding has-side-effects property.
llvm-svn: 212276
|
| |
|
|
|
|
|
|
|
|
| |
mode.
This also runs the test in that mode which would reproduce the crash.
What I love is that *every single FIXME* in the test is addressed by
switching to widening.
llvm-svn: 212254
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Finkel, Eric Christopher, and a bunch of other people I'm probably
forgetting (sorry), add an option to the x86 backend to widen vectors
during type legalization rather than promote them.
This still would promote vNi1 vectors to get the masks right, but would
widen other vectors. A lot of experiments are piling up right now
showing that widening should probably be the default legalization
strategy outside of vNi1 cases, but it is very hard to test the
rammifications of that and fix bugs in widening-based legalization
without an option that enables it. I'll be checking in tests shortly
that use this option to exercise cases where widening doesn't work well
and hopefully we'll be able to switch fully to this soon.
llvm-svn: 212249
|
| |
|
|
| |
llvm-svn: 212245
|
| |
|
|
| |
llvm-svn: 212244
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vector type legalization strategies in a more fine grained manner, and
change the legalization of several v1iN types and v1f32 to be widening
rather than scalarization on AArch64.
This fixes an assertion failure caused by scalarizing nodes like "v1i32
trunc v1i64". As v1i64 is legal it will fail to scalarize v1i32.
This also provides a foundation for other targets to have more granular
control over how vector types are legalized.
Patch by Hao Liu, reviewed by Tim Northover. I'm committing it to allow
some work to start taking place on top of this patch as it adds some
really important hooks to the backend that I'd like to immediately start
using. =]
http://reviews.llvm.org/D4322
llvm-svn: 212242
|
| |
|
|
|
|
|
| |
machine. Includes a fix for a subtarget initialization for
hard floating point on mips16.
llvm-svn: 212240
|
| |
|
|
|
|
|
| |
circular dependency with the subtarget by inlining accessor methods and
outlining a routine.
llvm-svn: 212236
|
| |
|
|
|
|
|
| |
circular dependency with the subtarget by inlining accessor methods and
outlining a routine.
llvm-svn: 212234
|
| |
|
|
| |
llvm-svn: 212228
|
| |
|
|
|
|
| |
down to the subtarget.
llvm-svn: 212224
|
| |
|
|
| |
llvm-svn: 212223
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This new multiclass, avx512_perm_table_3src derives from the current one and
provides the Pat<>. The next patch will add another Pat<> that uses the
writemask.
Note that I dropped the type annotation from the intrinsic call, i.e.: (v16f32
VR512:$src1) -> R512:$src1. I think that this should be fine (at least many
intrinsic calls don't provide them) and it greatly reduces the number of
template arguments.
llvm-svn: 212222
|
| |
|
|
|
|
|
|
|
| |
This includes assembler and codegen support (see the new tests in
avx512-encodings.s and avx512-shuffle.ll).
<rdar://problem/17492620>
llvm-svn: 212221
|
| |
|
|
| |
llvm-svn: 212218
|
| |
|
|
| |
llvm-svn: 212217
|
| |
|
|
| |
llvm-svn: 212216
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SGPRs are written by instructions that sometimes will ignore control flow,
which means if you have code like:
if (VGPR0) {
SGPR0 = S_MOV_B32 0
} else {
SGPR0 = S_MOV_B32 1
}
The value of SGPR0 will 1 no matter what the condition is.
In order to deal with this situation correctly, we need to view the
program as if it were a single basic block when we calculate the
live ranges for the SGPRs. They way we actually update the live
range is by iterating over all of the segments in each LiveRange
object and setting the end of each segment equal to the start of
the next segment. So a live range like:
[3888r,9312r:0)[10032B,10384B:0) 0@3888r
will become:
[3888r,10032B:0)[10032B,10384B:0) 0@3888r
This change will allow us to use SALU instructions within branches.
llvm-svn: 212215
|
| |
|
|
| |
llvm-svn: 212214
|
| |
|
|
|
|
|
|
|
|
|
|
| |
heuristic.
By default, no functionality change.
This is a follow-up of r212099.
This hook provides a finer grain to control the optimization.
<rdar://problem/17444599>
llvm-svn: 212204
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commits r212189 and r212190.
While this pass was accidentally disabled (until r212073), r205437
slipped in a use of `auto` that should have been `auto&`.
This fixes PR20188.
llvm-svn: 212201
|
| |
|
|
| |
llvm-svn: 212199
|
| |
|
|
|
|
|
| |
I don't think anything hits this now, but will be exposed in future
patches.
llvm-svn: 212197
|
| |
|
|
| |
llvm-svn: 212194
|
| |
|
|
|
|
|
| |
Temporarily disable AArch64AddressTypePromotion, which was effectively
re-enabled in r212073 and r212075, while I look into PR20188.
llvm-svn: 212189
|
| |
|
|
|
|
|
| |
CombineTo doesn't allow replacing a node with itself so this would crash if the
combined shuffle is the same as the input shuffle.
llvm-svn: 212181
|
| |
|
|
|
|
|
| |
After Alexey Volkov, I'm adding the same property for KNL, that prefers ADD/SUB instead of INC/DEC.
Added a test.
llvm-svn: 212178
|
| |
|
|
|
|
|
|
|
|
| |
Based on the support for .req on ARM. The aarch64 variant has to keep track if
the alias register was a vector register (v0-31) or a general purpose or
VFP/Advanced SIMD ([bhsdq]0-31) register.
Patch by Janne Grunau!
llvm-svn: 212161
|
| |
|
|
|
|
| |
a separate function and clean up calling convention for helper function.
llvm-svn: 212153
|
| |
|
|
| |
llvm-svn: 212152
|
| |
|
|
| |
llvm-svn: 212151
|
| |
|
|
| |
llvm-svn: 212150
|
| |
|
|
| |
llvm-svn: 212149
|
| |
|
|
|
|
| |
down to the subtarget.
llvm-svn: 212147
|
| |
|
|
|
|
| |
that information.
llvm-svn: 212146
|
| |
|
|
|
|
|
|
|
| |
Otherwise they get freed and the implicit "isa<XYZ>" tests following
turn out badly (at least under sanitizers).
Also corrects the ordering of unordered atomic stores.
llvm-svn: 212136
|
| |
|
|
|
|
|
|
| |
The argument list vector is never used after it has been passed to the
CallLoweringInfo and moving it to the CallLoweringInfo is cleaner and
pretty much as cheap as keeping a pointer to it.
llvm-svn: 212135
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On targets without cmpxchg16b or cmpxchg8b, the borderline atomic
operations were slipping through the gaps.
X86AtomicExpand.cpp was delegating to ISelLowering. Generic
ISelLowering was delegating to X86ISelLowering and X86ISelLowering was
asserting. The correct behaviour is to expand to a libcall, preferably
in generic ISelLowering.
This can be achieved by X86ISelLowering deciding it doesn't want the
faff after all.
llvm-svn: 212134
|
| |
|
|
|
|
| |
down to the subtarget. Add an initialization routine to assist.
llvm-svn: 212124
|
| |
|
|
|
|
| |
from SystemZFrameLowering.
llvm-svn: 212123
|
| |
|
|
| |
llvm-svn: 212120
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The logic for expanding atomics that aren't natively supported in
terms of cmpxchg loops is much simpler to express at the IR level. It
also allows the normal optimisations and CodeGen improvements to help
out with atomics, instead of using a limited set of possible
instructions..
rdar://problem/13496295
llvm-svn: 212119
|
| |
|
|
|
|
|
|
|
| |
For now I only updated the _alt variants. The main variants are used by
codegen and that will need a bit more work to trigger.
<rdar://problem/17492620>
llvm-svn: 212114
|
| |
|
|
|
|
|
|
|
| |
Adding a writemask variant would require a third asm string to be passed to
the template. Generate the AsmString in the template instead.
No change in X86.td.expanded.
llvm-svn: 212113
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
seh_stackalloc 0 is not representable in Win64 SEH info, so emitting it
is a bug.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D4334
Patch by Vadim Chugunov!
llvm-svn: 212081
|
| |
|
|
|
|
|
|
| |
In r212073 I missed a call of `use_begin()` that assumed the wrong
semantics. It's not clear to me at all what this code does without the
fix, so I'm not sure how to write a testcase.
llvm-svn: 212075
|
| |
|
|
|
|
|
|
| |
AArch64AddressTypePromotion was doing nothing because it was using the
old semantics of `Use` and `uses()`, when it really wanted to get at the
`users()`.
llvm-svn: 212073
|
| |
|
|
| |
llvm-svn: 212056
|
| |
|
|
| |
llvm-svn: 212052
|