| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
AT&T dialect. Test case for r179804 as well.
rdar://13674398 and PR13340.
llvm-svn: 179813
|
| |
|
|
|
|
|
| |
This seems to cause a stage-2 LLVM compile failure (by crashing TableGen); do
I'm disabling this for now.
llvm-svn: 179807
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many PPC instructions have a so-called 'record form' which stores to a specific
condition register the result of comparing the result of the instruction with
zero (always as a signed comparison). For integer operations on PPC64, this is
always a 64-bit comparison.
This implementation is derived from the implementation in the ARM backend;
there are some differences because PPC condition registers are allocatable
virtual registers (although the record forms always use a specific one), and we
look for a matching subtraction instruction after the compare (but before the
first use) in addition to before it.
llvm-svn: 179802
|
| |
|
|
|
|
|
|
| |
available.
This pattern started popping up in vectorized min/max reductions.
llvm-svn: 179797
|
| |
|
|
|
|
| |
limitation that extract is promoted over a cast only if the cast has only one use.
llvm-svn: 179786
|
| |
|
|
|
|
| |
it has only 2 uses: one to promote the vector phi in a loop and the other use is an extract operation of one element at a constant location.
llvm-svn: 179783
|
| |
|
|
|
|
|
| |
We are still able to handle mixed endian objects by swapping one struct at a
time.
llvm-svn: 179778
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In X86FastISel::X86SelectStore(), improperly aligned stores are rejected and
handled by the DAG-based ISel. However, X86FastISel::X86SelectLoad() makes
no such requirement. There doesn't appear to be an x86 architectural
correctness issue with allowing potentially unaligned store instructions.
This patch removes this restriction.
Patch by Jim Stichnot.
llvm-svn: 179774
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A min/max operation is represented by a select(cmp(lt/le/gt/ge, X, Y), X, Y)
sequence in LLVM. If we see such a sequence we can treat it just as any other
commutative binary instruction and reduce it.
This appears to help bzip2 by about 1.5% on an imac12,2.
radar://12960601
llvm-svn: 179773
|
| |
|
|
|
|
| |
Fixes PR15748.
llvm-svn: 179757
|
| |
|
|
| |
llvm-svn: 179751
|
| |
|
|
|
|
| |
It is causing stage2 builds to fail, let's get them running again.
llvm-svn: 179750
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simplify:
(select (icmp eq (and X, C1), 0), Y, (or Y, C2))
Into:
(or (shl (and X, C1), C3), y)
Where:
C3 = Log(C2) - Log(C1)
If:
C1 and C2 are both powers of two
llvm-svn: 179748
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
outside said for loop in the presense of differing provenance caused by escaping blocks.
This occurs due to an alloca representing a separate ownership from the
original pointer. Thus consider the following pseudo-IR:
objc_retain(%a)
for (...) {
objc_retain(%a)
%block <- %a
F(%block)
objc_release(%block)
}
objc_release(%a)
From the perspective of the optimizer, the %block is a separate
provenance from the original %a. Thus the optimizer pairs up the inner
retain for %a and the outer release from %a, resulting in segfaults.
This is fixed by noting that the signature of a mismatch of
retain/releases inside the for loop is a Use/CanRelease top down with an
None bottom up (since bottom up the Retain-CanRelease-Use-Release
sequence is completed by the inner objc_retain, but top down due to the
differing provenance from the objc_release said sequence is not
completed). In said case in CheckForCFGHazards, we now clear the state
of %a implying that no pairing will occur.
Additionally a test case is included.
rdar://12969722
llvm-svn: 179747
|
| |
|
|
|
|
| |
extra coverage) and set it up to use FileCheck variables to make the test more robust.
llvm-svn: 179745
|
| |
|
|
| |
llvm-svn: 179739
|
| |
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D598
llvm-svn: 179725
|
| |
|
|
|
|
|
|
|
|
|
| |
unable to handle cases such as __asm mov eax, 8*-8.
This patch also attempts to simplify the state machine. Further, the error
reporting has been improved. Test cases included, but more will be added to
the clang side shortly.
rdar://13668445
llvm-svn: 179719
|
| |
|
|
|
|
|
|
|
| |
for the sdiv/srem/udiv/urem bitcode instructions. This is done for the i8,
i16, and i32 types, as well as i64 for the x86_64 target.
Patch by Jim Stichnoth
llvm-svn: 179715
|
| |
|
|
|
|
|
|
| |
getSimpleVT can only handle simple value types.
radar://13676022
llvm-svn: 179714
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reference manual defines only 5 permitted values for the immediate field of the "hint" instruction:
1. nop (imm == 0)
2. yield (imm == 1)
3. wfe (imm == 2)
4. wfi (imm == 3)
5. sev (imm == 4)
Therefore, restrict the permitted values for the "hint" instruction to 0 through 4.
Patch by Mihail Popa <Mihail.Popa@arm.com>
llvm-svn: 179707
|
| |
|
|
| |
llvm-svn: 179686
|
| |
|
|
| |
llvm-svn: 179667
|
| |
|
|
|
|
|
|
| |
add a test case
CR feedback from Rafael Espindola and Paul Robinson.
llvm-svn: 179664
|
| |
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D620
llvm-svn: 179661
|
| |
|
|
|
|
|
|
|
|
| |
This patch allows the Mips assembler to parse and emit nested
expressions as instruction operands. It also extends the
expansion of memory instructions when an offset is given as
an expression.
Contributer: Vladimir Medic
llvm-svn: 179657
|
| |
|
|
| |
llvm-svn: 179621
|
| |
|
|
|
|
| |
I intend to extend the test with more offset folding checks
llvm-svn: 179620
|
| |
|
|
| |
llvm-svn: 179619
|
| |
|
|
| |
llvm-svn: 179591
|
| |
|
|
|
|
| |
crashes llvm-objdump on relocated objects with large bss
llvm-svn: 179589
|
| |
|
|
|
|
|
|
|
|
|
| |
If a switch instruction has a case for every possible value of its type,
with the same successor, SimplifyCFG would replace it with an icmp ult,
but the computation of the bound overflows in that case, which inverts
the test.
Patch by Jed Davis!
llvm-svn: 179587
|
| |
|
|
| |
llvm-svn: 179582
|
| |
|
|
|
|
|
|
|
| |
These are aliases for VACGT and VACGE, respectively, with the source
operands reversed.
rdar://13638090
llvm-svn: 179575
|
| |
|
|
|
|
|
|
| |
Two return types are not equivalent if one is a pointer and the other is an
integral. This is because we cannot bitcast a pointer to an integral value.
PR15185
llvm-svn: 179569
|
| |
|
|
|
|
|
|
|
|
| |
This patch allows the assembler to recognize $fcc0
as a valid register for conditional move instructions.
Corresponding test cases have been added.
Contributer: Vladimir Medic
llvm-svn: 179567
|
| |
|
|
|
|
| |
vector-gather sequence out of loops.
llvm-svn: 179562
|
| |
|
|
|
|
|
|
| |
Instead of emitting config values in a predefined order, the code
emitter will now emit a 32-bit register index followed by the 32-bit
config value.
llvm-svn: 179546
|
| |
|
|
| |
llvm-svn: 179545
|
| |
|
|
| |
llvm-svn: 179544
|
| |
|
|
| |
llvm-svn: 179532
|
| |
|
|
|
|
|
|
|
|
|
| |
I can fix the testcases here:
http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/6952
This reverts commit r179512 due to testcases specifying triples
that they didn't actually mean and causing failures on other platforms.
llvm-svn: 179513
|
| |
|
|
| |
llvm-svn: 179512
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 179504
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an ABI bug for non-Darwin PPC64. For the callee-saved condition
registers, the spill location is specified relative to the stack pointer (SP +
8). However, this is not relative to the SP after the new stack frame is
established, but instead relative to the caller's stack pointer (it is stored
into the linkage area of the parent's stack frame).
So, like with the link register, we don't directly spill the CRs with other
callee-saved registers, but just mark them to be spilled during prologue
generation.
In practice, this reverts r179457 for PPC64 (but leaves it in place for PPC32).
llvm-svn: 179500
|
| |
|
|
|
|
| |
This reverts commit r179497 and the accompanying commit as it broke random platforms that aren't osx.
llvm-svn: 179499
|
| |
|
|
| |
llvm-svn: 179498
|
| |
|
|
| |
llvm-svn: 179494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One performs: (X == 13 | X == 14) -> X-13 <u 2
The other: (A == C1 || A == C2) -> (A & ~(C1 ^ C2)) == C1
The problem is that there are certain values of C1 and C2 that
trigger both transforms but the first one blocks out the second,
this generates suboptimal code.
Reordering the transforms should be better in every case and
allows us to do interesting stuff like turn:
%shr = lshr i32 %X, 4
%and = and i32 %shr, 15
%add = add i32 %and, -14
%tobool = icmp ne i32 %add, 0
into:
%and = and i32 %X, 240
%tobool = icmp ne i32 %and, 224
llvm-svn: 179493
|
| |
|
|
| |
llvm-svn: 179492
|