| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Emit the ARM build attributes ABI_PCS_wchar_t and ABI_enum_size based on
module flags metadata.
llvm-svn: 211349
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3897
llvm-svn: 211346
|
| |
|
|
|
|
|
| |
Remove an unused AMDIL leftover, correct extra periods
appearing in the help menu.
llvm-svn: 211341
|
| |
|
|
|
|
|
|
|
| |
This patch adds support to recognize patterns such as fadd,fsub,fadd,fsub.../add,sub,add,sub... and
vectorizes them as vector shuffles if they are profitable.
These patterns of vector shuffle can later be converted to instructions such as addsubpd etc on X86.
Thanks to Arnold and Hal for the reviews. http://reviews.llvm.org/D4015
llvm-svn: 211339
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions available as synthetic SDNodes PACKSS and PACKUS that will
select to the correct instruction variants based on the return type.
This allows us to use these rather important instructions when lowering
vector shuffles.
Also moves the relevant instruction definitions to be split out from
the fully generic multiclasses to allow them to match these new SDNodes
in the same way that the UNPCK instructions do.
No functionality should actually be changed here.
llvm-svn: 211332
|
| |
|
|
|
|
|
|
|
| |
the atomic load linked expander pass to run for a particular
subtarget. This requires a check of the subtarget and so save
the TargetMachine rather than only TargetLoweringInfo and update
all callers.
llvm-svn: 211314
|
| |
|
|
| |
llvm-svn: 211304
|
| |
|
|
|
|
|
|
|
|
|
| |
Patch by David Chisnall
His work was sponsored by: DARPA, AFRL
Some small modifications to the original patch: we now error if
it's not possible to expand an instruction (mips-expansions-bad.s has some
examples). Added some comments to the expansions.
llvm-svn: 211271
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions.
Summary:
The functions that do the expansion now return false on success and true otherwise. This is so
we can catch some errors during the expansion (e.g.: immediate too large). The next patch adds some test cases.
Reviewers: vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D4214
llvm-svn: 211269
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change, the backend was unable to fold a build_vector dag
node with UNDEF operands into a single horizontal add/sub.
This patch teaches how to combine a build_vector with UNDEF operands into a
horizontal add/sub when possible. The algorithm conservatively avoids to combine
a build_vector with only a single non-UNDEF operand.
Added test haddsub-undef.ll to verify that we correctly fold horizontal binop
even in the presence of UNDEFs.
llvm-svn: 211265
|
| |
|
|
|
|
| |
the assert.
llvm-svn: 211254
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We would get confused by '@' characters in symbol names, we would
mistake the text following them for the variant kind.
When an identifier a string, the variant kind will never show up inside
of it. Instead, check to see if there is a variant following the
string.
This fixes PR19965.
llvm-svn: 211249
|
| |
|
|
|
|
|
|
| |
These will be used for custom lowering and for library
implementations of various math functions, so it's useful
to expose these as builtins.
llvm-svn: 211247
|
| |
|
|
|
|
|
|
|
| |
This required untangling a mess of headers that included around.
This a recommit of r210953 with a fix for the removed accessor
for JITInfo.
llvm-svn: 211233
|
| |
|
|
| |
llvm-svn: 211231
|
| |
|
|
|
|
|
|
| |
The difference from rint isn't really relevant here,
so treat them as equivalent. OpenCL doesn't have nearbyint,
so this is sort of pointless other than for completeness.
llvm-svn: 211229
|
| |
|
|
|
|
|
|
|
| |
This contains all the previous patches + getlod support on top of it.
It doesn't use SDNodes anymore, so it's quite small.
It also adds v16i8 to SReg_128, which is used for the sampler descriptor.
Reviewed-by: Tom Stellard
llvm-svn: 211228
|
| |
|
|
|
|
| |
This hopefully fixes Windows
llvm-svn: 211225
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When looking at the 64-bit SVR4 indirect call sequence, I noticed
an unnecessary load of r12. And indeed the code says:
// R12 must contain the address of an indirect callee.
But this is not correct; in the 64-bit SVR4 (ELFv1) ABI, there is
no need to load r12 at this point. It seems this code and comment
is a remnant of code originally shared with the Darwin ABI ...
This patch simply removes the unnecessary load.
llvm-svn: 211203
|
| |
|
|
|
|
|
|
|
|
|
| |
ARMTargetStreamer implements ConstantPool and AssmeblerConstantPools
to keep track of assembler-generated constant pools that are used for
ldr-pseudo.
When implementing ldr-pseudo for AArch64, these two classes can be reused.
So this patch factors them out from ARM target to the general MC lib.
llvm-svn: 211198
|
| |
|
|
|
|
|
|
|
| |
Move fp64 fceil tests to fceil64.ll
v2: rebase
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 211194
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During an indirect function call sequence on the 64-bit SVR4 ABI,
generate code must load and then restore the TOC register.
This does not use a regular LOAD instruction since the TOC
register r2 is marked as reserved. Instead, the are two
special instruction patterns:
let RST = 2, DS = 2 in
def LDinto_toc: DSForm_1a<58, 0, (outs), (ins g8rc:$reg),
"ld 2, 8($reg)", IIC_LdStLD,
[(PPCload_toc i64:$reg)]>, isPPC64;
let RST = 2, DS = 10, RA = 1 in
def LDtoc_restore : DSForm_1a<58, 0, (outs), (ins),
"ld 2, 40(1)", IIC_LdStLD,
[(PPCtoc_restore)]>, isPPC64;
Note that these not only restrict the destination of the
load to r2, but they also restrict the *source* of the
load to particular address combinations. The latter is
a problem when we want to support the ELFv2 ABI, since
there the TOC save slot is no longer at 40(1).
This patch replaces those two instructions with a single
instruction pattern that only hard-codes r2 as destination,
but supports generic addresses as source. This will allow
supporting the ELFv2 ABI, and also helps generate more
efficient code for calls to absolute addresses (allowing
simplification of the ppc64-calls.ll test case).
llvm-svn: 211193
|
| |
|
|
|
|
| |
Apparently C++ doesn't really have hex floating point constants.
llvm-svn: 211192
|
| |
|
|
| |
llvm-svn: 211187
|
| |
|
|
|
|
| |
Copy what is done for 32-bit already so the order is about the same.
llvm-svn: 211186
|
| |
|
|
|
|
| |
but SYNC with an implied operand ($stype = 0) is valid since Mips2.
llvm-svn: 211185
|
| |
|
|
|
|
| |
CI has instructions for these, so this fixes them for older hardware.
llvm-svn: 211183
|
| |
|
|
| |
llvm-svn: 211182
|
| |
|
|
|
|
|
| |
This should be a source modifier, but this unblocks
most of my math patches.
llvm-svn: 211181
|
| |
|
|
| |
llvm-svn: 211178
|
| |
|
|
|
|
|
|
|
|
|
| |
Note that I followed the AVX2 convention here and didn't add LLVM intrinsics
for stores. These can be generated with the nontemporal hint on LLVM IR
stores (see new test). The GCC builtins are lowered directly into nontemporal
stores.
<rdar://problem/17082571>
llvm-svn: 211176
|
| |
|
|
|
|
|
| |
Use the max 64-bit element size with EVEX_CD8. This should work since element
size is ignored for a full-vector access (FVM).
llvm-svn: 211175
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PowerPC back-end uses BLA to implement calls to functions at
known-constant addresses, which is apparently used for certain
system routines on Darwin.
However, with the 64-bit SVR4 ABI, this is actually incorrect.
An immediate function pointer value on this platform is not
directly usable as a target address for BLA:
- in the ELFv1 ABI, the function pointer value refers to the
*function descriptor*, not the code address
- in the ELFv2 ABI, the function pointer value refers to the
global entry point, but BL(A) would only be correct when
calling the *local* entry point
This bug didn't show up since using immediate function pointer
values is not usually done in the 64-bit SVR4 ABI in the first
place. However, I ran into this issue with a certain use case
of LLVM as JIT, where immediate function pointer values were
uses to implement callbacks from JITted code to helpers in
statically compiled code.
Fixed by simply not using BLA with the 64-bit SVR4 ABI.
llvm-svn: 211174
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
My patch r204634 to emit instructions in little-endian format failed to
handle those special cases where we emit a pair of instructions from a
single LLVM MC instructions (like the bl; nop pairs used to implement
the call sequence).
In those cases, we still need to emit the "first" instruction (the one
in the more significant word) first, on both big and little endian,
and not swap them.
llvm-svn: 211171
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The assembler tries to reuse the destination register for memory operations whenever
it can but it's not possible to do so if the destination register is not a GPR.
Example:
ldc1 $f0, sym
should expand to:
lui $at, %hi(sym)
ldc1 $f0, %lo(sym)($at)
It's entirely wrong to expand to:
lui $f0, %hi(sym)
ldc1 $f0, %lo(sym)($f0)
Reviewers: dsanders
Reviewed By: dsanders
Differential Revision: http://reviews.llvm.org/D4173
llvm-svn: 211169
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
it's not available.
Summary: This removes the FIXMEs from test/MC/Mips/mips-noat.s.
Reviewers: dsanders
Reviewed By: dsanders
Differential Revision: http://reviews.llvm.org/D4172
llvm-svn: 211168
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3923
llvm-svn: 211167
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch doesn't really change the logic behind expandMemInst but it allows
us to assemble .S files that use .set noat with some macros. For example:
.set noat
lw $k0, offset($k1)
Can expand to:
lui $k0, %hi(offset)
addu $k0, $k0, $k1
lw $k0, %lo(offset)($k0)
with no need to access $at.
Reviewers: dsanders, vmedic
Reviewed By: dsanders, vmedic
Differential Revision: http://reviews.llvm.org/D4159
llvm-svn: 211165
|
| |
|
|
| |
llvm-svn: 211164
|
| |
|
|
|
|
|
|
|
|
|
|
| |
start with the binary operator NOT (~).
Reviewers: dsanders
Reviewed By: dsanders
Differential Revision: http://reviews.llvm.org/D4158
llvm-svn: 211163
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Examples:
and $2, 4 <=> andi $2, $2, 4
or $2, 4 <=> ori $2, $2, 4
Reviewers: dsanders
Reviewed By: dsanders
Differential Revision: http://reviews.llvm.org/D4155
llvm-svn: 211161
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Added negative test case so that we can be sure we handle erroneous situations
while parsing the .cpsetup directive.
Reviewers: dsanders
Reviewed By: dsanders
Differential Revision: http://reviews.llvm.org/D3681
llvm-svn: 211160
|
| |
|
|
|
|
|
| |
v2: Use capitalized variable name
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 211159
|
| |
|
|
|
|
|
| |
v2: use C++ style comment
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 211158
|
| |
|
|
|
|
|
| |
v2: Use c++ style comment
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 211157
|
| |
|
|
|
|
|
|
|
| |
ReconstructShuffle() may wrongly creat a CONCAT_VECTOR trying to
concat 2 of v2i32 into v4i16. This commit is to fix this issue and
try to generate UZP1 instead of lots of MOV and INS.
Patch is initalized by Kevin Qin, and refactored by Tim Northover.
llvm-svn: 211144
|
| |
|
|
| |
llvm-svn: 211141
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch is a follow up to r211040 & r211052. Rather than bailing out of fast
isel this patch will generate an alternate instruction (movabsq) instead of the
leaq. While this will always have enough room to handle the 64 bit displacment
it is generally over kill for internal symbols (most displacements will be
within 32 bits) but since we have no way of communicating the code model to the
the assmebler in order to avoid flagging an absolute leal/leaq as illegal when
using a symbolic displacement.
llvm-svn: 211130
|
| |
|
|
|
|
|
|
|
| |
This optimizes predicates for certain compares, such as fcmp oeq %x, %x to
fcmp ord %x, %x. The latter one is more efficient to generate.
The same optimization is applied to conditional branches.
llvm-svn: 211126
|
| |
|
|
| |
llvm-svn: 211120
|