| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 216681
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove a block of code from LowerSIGN_EXTEND_INREG() that was added with:
http://llvm.org/viewvc/llvm-project?view=revision&revision=177421
And caused:
http://llvm.org/bugs/show_bug.cgi?id=20472 (more analysis here)
http://llvm.org/bugs/show_bug.cgi?id=18054
The testcases confirm that we (1) don't remove a zext op that is necessary and (2) generate
a pmovz instead of punpck if SSE4.1 is available. Although pmovz is 1 byte longer, it allows
folding of the load, and so saves 3 bytes overall.
Differential Revision: http://reviews.llvm.org/D4909
llvm-svn: 216679
|
| |
|
|
|
|
|
|
|
| |
SHUFFLE_VECTOR
was marked custom. The target independent DAG combine has no way to know if
the shuffles it is introducing are ones that the target could support or not.
llvm-svn: 216678
|
| |
|
|
|
|
| |
beginning of the comment."
llvm-svn: 216674
|
| |
|
|
|
|
| |
functional change.
llvm-svn: 216673
|
| |
|
|
|
|
|
| |
Completes what was started in r216611 and r216623.
Used const refs instead of pointers; not sure if one is preferable to the other.
llvm-svn: 216672
|
| |
|
|
|
|
|
|
| |
Reviewers: adasgupt, jverma, sidneym
Differential Revision: http://reviews.llvm.org/D5025
llvm-svn: 216667
|
| |
|
|
| |
llvm-svn: 216666
|
| |
|
|
| |
llvm-svn: 216660
|
| |
|
|
|
|
|
|
| |
InstSimplify already handles icmp (X+Y), X (and things like it)
appropriately. The first thing that InstCombine does is run
InstSimplify on the instruction.
llvm-svn: 216659
|
| |
|
|
|
|
|
|
|
|
| |
vector instruction.
For a detailed description of the problem see the comment in the test file.
The problematic moveBefore() calls are not required anymore because the new
scheduling algorithm ensures a correct ordering anyway.
llvm-svn: 216656
|
| |
|
|
| |
llvm-svn: 216651
|
| |
|
|
| |
llvm-svn: 216650
|
| |
|
|
|
|
| |
More work on http://llvm.org/PR20640
llvm-svn: 216648
|
| |
|
|
|
|
|
| |
I've decided not to commit a test, it takes 2.5 seconds to run on my an
incredibly strong machine.
llvm-svn: 216647
|
| |
|
|
|
|
| |
clang-format, no functionality changed.
llvm-svn: 216646
|
| |
|
|
|
|
|
|
|
|
|
| |
a single early exit.
And factor the subsequent cast<> from all but one block into a single
variable.
No functionality changed.
llvm-svn: 216645
|
| |
|
|
|
|
|
|
|
|
| |
functionality changed.
Separating this into two functions wasn't helping. There was a decent
amount of boilerplate duplicated, and some subsequent refactorings here
will pull even more common code out.
llvm-svn: 216644
|
| |
|
|
|
|
|
|
| |
Several combines involving icmp (shl C2, %X) C1 can be simplified
without introducing any new instructions. Move them to InstSimplify;
while we are at it, make them more powerful.
llvm-svn: 216642
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The included test case would fail, because the MI PHI node would have two
operands from the same predecessor.
This problem occurs when a switch instruction couldn't be selected. This happens
always, because there is no default switch support for FastISel to begin with.
The problem was that FastISel would first add the operand to the PHI nodes and
then fall-back to SelectionDAG, which would then in turn add the same operands
to the PHI nodes again.
This fix removes these duplicate PHI node operands by reseting the
PHINodesToUpdate to its original state before FastISel tried to select the
instruction.
This fixes <rdar://problem/18155224>.
llvm-svn: 216640
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently instructions are folded very aggressively for AArch64 into the memory
operation, which can lead to the use of killed operands:
%vreg1<def> = ADDXri %vreg0<kill>, 2
%vreg2<def> = LDRBBui %vreg0, 2
... = ... %vreg1 ...
This usually happens when the result is also used by another non-memory
instruction in the same basic block, or any instruction in another basic block.
This fix teaches hasTrivialKill to not only check the LLVM IR that the value has
a single use, but also to check if the register that represents that value has
already been used. This can happen when the instruction with the use was folded
into another instruction (in this particular case a load instruction).
This fixes rdar://problem/18142857.
llvm-svn: 216634
|
| |
|
|
|
|
|
|
| |
the memory operation."
Quentin pointed out that this is not the correct approach and there is a better and easier solution.
llvm-svn: 216632
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Introduce support::ulittleX_t::ref type to Support/Endian.h and use it in x86 JIT
to enforce correct endianness and fix unaligned accesses.
Test Plan: regression test suite
Reviewers: lhames
Subscribers: ributzka, llvm-commits
Differential Revision: http://reviews.llvm.org/D5011
llvm-svn: 216631
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operation.
Currently instructions are folded very aggressively into the memory operation,
which can lead to the use of killed operands:
%vreg1<def> = ADDXri %vreg0<kill>, 2
%vreg2<def> = LDRBBui %vreg0, 2
... = ... %vreg1 ...
This usually happens when the result is also used by another non-memory
instruction in the same basic block, or any instruction in another basic block.
If the computed address is used by only memory operations in the same basic
block, then it is safe to fold them. This is because all memory operations will
fold the address computation and the original computation will never be emitted.
This fixes rdar://problem/18142857.
llvm-svn: 216629
|
| |
|
|
| |
llvm-svn: 216623
|
| |
|
|
| |
llvm-svn: 216622
|
| |
|
|
|
|
|
|
|
| |
When the address comes directly from a shift instruction then the address
computation cannot be folded into the memory instruction, because the zero
register is not available as a base register. Simplify addess needs to emit the
shift instruction and use the result as base register.
llvm-svn: 216621
|
| |
|
|
|
|
| |
Unfortunately this is only used by ld64, so no testcase, but should fix the darwin LTO bootstrap.
llvm-svn: 216618
|
| |
|
|
|
|
|
|
|
| |
Use the zero register directly when possible to avoid an unnecessary register
copy and a wasted register at -O0. This also uses integer stores to store a
positive floating-point zero. This saves us from materializing the positive zero
in a register and then storing it.
llvm-svn: 216617
|
| |
|
|
| |
llvm-svn: 216616
|
| |
|
|
|
|
|
|
| |
FastEmitInst_ri was constraining the first operand without checking if it is
a virtual register. Use constrainOperandRegClass as all the other
FastEmitInst_* functions.
llvm-svn: 216613
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 216611
|
| |
|
|
| |
llvm-svn: 216609
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instructions like 'fxsave' and control flow instructions like 'jne'
match any operand size. The loop I added to the Intel syntax matcher
assumed that using a different size would give a different instruction.
Now it handles the case where we get the same instruction for different
memory operand sizes.
This also allows us to remove the hack we had for unsized absolute
memory operands, because we can successfully match things like 'jnz'
without reporting ambiguity. Removing this hack uncovered test case
involving 'fadd' that was ambiguous. The memory operand could have been
single or double precision.
llvm-svn: 216604
|
| |
|
|
|
|
|
|
| |
We try to perform this transform in InstSimplify but we aren't always
able to. Sometimes, we need to insert a bitcast if X and Y don't have
the same time.
llvm-svn: 216598
|
| |
|
|
|
|
|
|
|
| |
It's incorrect to perform this simplification if the types differ.
A bitcast would need to be inserted for this to work.
This fixes PR20771.
llvm-svn: 216597
|
| |
|
|
| |
llvm-svn: 216586
|
| |
|
|
| |
llvm-svn: 216583
|
| |
|
|
|
|
| |
It caused PR 20771. I'll land a test on the clang side.
llvm-svn: 216582
|
| |
|
|
| |
llvm-svn: 216580
|
| |
|
|
|
|
|
| |
int may not have enough bits in it, which was detected by UBSan
bootstrap (it reported left shift by a too large constant).
llvm-svn: 216579
|
| |
|
|
|
|
| |
In fact, most users were already using the StringRef version.
llvm-svn: 216575
|
| |
|
|
|
|
|
|
| |
'shl nuw CI, x' produces [CI, CI << CLZ(CI)]
'shl nsw CI, x' produces [CI << CLO(CI)-1, CI] if CI is negative
'shl nsw CI, x' produces [CI, CI << CLZ(CI)-1] if CI is non-negative
llvm-svn: 216570
|
| |
|
|
|
|
|
|
| |
opened."
This reverts commit r216563, which breaks lli's dynamic symbol resolution.
llvm-svn: 216569
|
| |
|
|
| |
llvm-svn: 216568
|
| |
|
|
|
|
| |
http://llvm.org/PR20640
llvm-svn: 216567
|
| |
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D5030
Reviewed By: Reid Kleckner, Rafael Espindola
llvm-svn: 216563
|
| |
|
|
|
|
|
|
| |
This teaches the AArch64 backend to deal with the operations required
to deal with the operations on v4f16 and v8f16 which are exposed by
NEON intrinsics, plus the add, sub, mul and div operations.
llvm-svn: 216555
|
| |
|
|
| |
llvm-svn: 216549
|
| |
|
|
|
|
| |
r216536 mistakenly used -style=Google instead of LLVM.
llvm-svn: 216543
|