| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 211268
|
| |
|
|
|
|
|
|
|
|
|
|
| |
subtraction (Part 1)
This patch enables transforms for following patterns.
(x + (~(y & c) + 1) --> x - (y & c)
(x + (~((y >> z) & c) + 1) --> x - ((y>>z) & c)
Differential Revision: http://reviews.llvm.org/D3733
llvm-svn: 211266
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Find factorization opportunities using identity values.
* Find factorization opportunities by treating shl(X, C) as mul (X, shl(C))
* Keep NSW flag while simplifying instruction using factorization.
This fixes PR19263.
Differential Revision: http://reviews.llvm.org/D3799
llvm-svn: 211261
|
| |
|
|
|
|
|
|
|
|
| |
These errors are strictly unrecoverable and indicate serious issues such as
conflicting option names or an incorrectly linked LLVM distribution.
With this change, the errors actually get detected so tests don't pass
silently.
llvm-svn: 211260
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InstCombineMulDivRem has:
// Canonicalize (X+C1)*CI -> X*CI+C1*CI.
InstCombineAddSub has:
// W*X + Y*Z --> W * (X+Z) iff W == Y
These two transforms could fight with each other if C1*CI would not fold
away to something simpler than a ConstantExpr mul.
The InstCombineMulDivRem transform only acted on ConstantInts until
r199602 when it was changed to operate on all Constants in order to
let it fire on ConstantVectors.
To fix this, make this transform more careful by checking to see if we
actually folded away C1*CI.
This fixes PR20079.
llvm-svn: 211258
|
| |
|
|
|
|
|
| |
used by all of the MC level tools and codegen. Fix up all uses
in the compiler to use this and set it on the context accordingly.
llvm-svn: 211257
|
| |
|
|
| |
llvm-svn: 211256
|
| |
|
|
|
|
| |
the assert.
llvm-svn: 211254
|
| |
|
|
|
|
| |
instsimplify. Patch by Rahul Jain, plus some last minute changes by me -- you can blame me for any bugs.
llvm-svn: 211252
|
| |
|
|
|
|
| |
whether the icmp is always true or false. Patch by Suyog Sarda!
llvm-svn: 211251
|
| |
|
|
|
|
| |
instsimplify already does this and instcombine calls instsimplify a few lines above. Patch by Suyog Sarda!
llvm-svn: 211250
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
fat files containing archives.
Also fix a bug in MachOUniversalBinary::ObjectForArch::ObjectForArch()
where it needed a >= when comparing the Index with the number of
objects in a fat file. As the index starts at 0.
llvm-svn: 211230
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Fixes macros with varargs if the macro instantiation has a trailing comment.
Patch by Janne Grunau!
llvm-svn: 211219
|
| |
|
|
|
|
| |
Patch by Janne Grunau!
llvm-svn: 211218
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This change has a bit of a trickle down effect due to the fact that
there are a number of derived implementations of ExecutionEngine,
and that the mutex is not tightly encapsulated so is used by other
classes directly.
Reviewed by: rnk
Differential Revision: http://reviews.llvm.org/D4196
llvm-svn: 211214
|
| |
|
|
|
|
|
| |
LLVMGetBitcodeModuleInContext should not take ownership on error. I will
try to localize this odd api requirement, but this should get the bots green.
llvm-svn: 211213
|
| |
|
|
|
|
| |
Thanks to David Majnemer for noticing.
llvm-svn: 211208
|
| |
|
|
|
|
|
| |
The main point of this class is to provide a cheap object interface to a bitcode
file, so it has to be as lazy as possible.
llvm-svn: 211207
|
| |
|
|
|
|
|
|
|
|
| |
We do have use cases for the bitcode reader owning the buffer or not, but we
always know which one we have when we construct it.
It might be possible to simplify this further, but this is a step in the
right direction.
llvm-svn: 211205
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When emitting optimization remarks, we test for the presence of
instruction locations by testing for a valid llvm.dbg.cu annotation.
This is slightly inefficient because we can simply ask whether the
debug location we have is known or not.
Additionally, if my current plan works, I will need to remove the
llvm.dbg.cu annotation from the IL (or prevent it from being generated)
when -Rpass is used without -g. In those cases, we'll want to generate
line tables but we will want to prevent code generation from emitting
DWARF code for them.
Tested on x86_64.
llvm-svn: 211204
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 211201
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 211184
|
| |
|
|
|
|
| |
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
|