| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 146981
|
|
|
|
| |
llvm-svn: 146805
|
|
|
|
|
|
|
|
|
| |
The bad sorting caused a misaligned basic block when building 176.vpr in
ARM mode.
<rdar://problem/10594653>
llvm-svn: 146767
|
|
|
|
|
|
|
|
|
|
| |
to finalize MI bundles (i.e. add BUNDLE instruction and computing register def
and use lists of the BUNDLE instruction) and a pass to unpack bundles.
- Teach more of MachineBasic and MachineInstr methods to be bundle aware.
- Switch Thumb2 IT block to MI bundles and delete the hazard recognizer hack to
prevent IT blocks from being broken apart.
llvm-svn: 146542
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I followed three heuristics for deciding whether to set 'true' or
'false':
- Everything target independent got 'true' as that is the expected
common output of the GCC builtins.
- If the target arch only has one way of implementing this operation,
set the flag in the way that exercises the most of codegen. For most
architectures this is also the likely path from a GCC builtin, with
'true' being set. It will (eventually) require lowering away that
difference, and then lowering to the architecture's operation.
- Otherwise, set the flag differently dependending on which target
operation should be tested.
Let me know if anyone has any issue with this pattern or would like
specific tests of another form. This should allow the x86 codegen to
just iteratively improve as I teach the backend how to differentiate
between the two forms, and everything else should remain exactly the
same.
llvm-svn: 146370
|
|
|
|
|
|
| |
SDNodes. Mark these nodes as illegal by default, unless the target declares otherwise.
llvm-svn: 146171
|
|
|
|
|
|
| |
instead of 'volatile load', which is archaic.
llvm-svn: 145171
|
|
|
|
|
|
| |
integer variants. rdar://10437054
llvm-svn: 144608
|
|
|
|
|
|
|
| |
Canonicallize on the non-suffixed form, but continue to accept assembly that
has any correctly sized type suffix.
llvm-svn: 144583
|
|
|
|
| |
llvm-svn: 144472
|
|
|
|
| |
llvm-svn: 144460
|
|
|
|
|
|
|
| |
This matches clang, so default options in llc and friends are now closer to
clang's defaults.
llvm-svn: 140863
|
|
|
|
| |
llvm-svn: 140585
|
|
|
|
| |
llvm-svn: 140567
|
|
|
|
| |
llvm-svn: 139577
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
register dependency (rather than glue them together). This is general
goodness as it gives scheduler more freedom. However it is motivated by
a nasty bug in isel.
When a i64 sub is expanded to subc + sube.
libcall #1
\
\ subc
\ / \
\ / \
\ / libcall #2
sube
If the libcalls are not serialized (i.e. both have chains which are dag
entry), legalizer can serialize them in arbitrary orders. If it's
unlucky, it can force libcall #2 before libcall #1 in the above case.
subc
|
libcall #2
|
libcall #1
|
sube
However since subc and sube are "glued" together, this ends up being a
cycle when the scheduler combine subc and sube as a single scheduling
unit.
The right solution is to fix LegalizeType too chains the libcalls together.
However, LegalizeType is not processing nodes in order so that's harder than
it should be. For now, the move to physical register dependency will do.
rdar://10019576
llvm-svn: 138791
|
|
|
|
| |
llvm-svn: 138116
|
|
|
|
|
|
|
|
| |
Fix base register type and canonicallize to the "ldm" spelling rather than
"ldmia." Add diagnostics for incorrect writeback token and out-of-range
registers.
llvm-svn: 137986
|
|
|
|
|
|
| |
correctly active without HasT2ExtractPack. PR10611.
llvm-svn: 137061
|
|
|
|
| |
llvm-svn: 136826
|
|
|
|
|
|
|
| |
(including compilation, assembly). Move relocation model Reloc::Model from
TargetMachine to MCCodeGenInfo so it's accessible even without TargetMachine.
llvm-svn: 135468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if (x != 0) x = 1
if (x == 1) x = 1
Previous codegen looks like this:
mov r1, r0
cmp r1, #1
mov r0, #0
moveq r0, #1
The naive lowering select between two different values. It should recognize the
test is equality test so it's more a conditional move rather than a select:
cmp r0, #1
movne r0, #0
rdar://9758317
llvm-svn: 135017
|
|
|
|
|
|
|
| |
Use memory barriers to force if-conversion off for these tests instead of
the internal llc command line option ifcvt-limit.
llvm-svn: 134986
|
|
|
|
|
|
|
|
|
|
| |
The normal tBX instruction is predicable, so there's no reason the
pseudos for using it as a return shouldn't be. Gives us some nice code-gen
improvements as can be seen by the test changes. In particular, several
tests now have to disable if-conversion because it works too well and defeats
the test.
llvm-svn: 134746
|
|
|
|
| |
llvm-svn: 134667
|
|
|
|
|
|
| |
them down to MC layer. Also fix tests.
llvm-svn: 134590
|
|
|
|
|
|
|
| |
makes one of the tests actually mean something (as the string 'add' will
always appear in the output of this file).
llvm-svn: 134358
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DSP instructions in the Thumb2 instruction set are an optional extension
in the Cortex-M* archtitecture. When present, the implementation is considered
an "ARMv7E-M implementation," and when not, an "ARMv7-M implementation."
Add a subtarget feature hook for the v7e-m instructions and hook it up. The
cortex-m3 cpu is an example of a v7m implementation, while the cortex-m4 is
a v7e-m implementation.
rdar://9572992
llvm-svn: 134261
|
|
|
|
|
|
|
|
|
| |
Fix a FIXME and allow predication (in Thumb2) for the T1 register to
register MOV instructions. This allows some better codegen with
if-conversion (as seen in the test updates), plus it lays the groundwork
for pseudo-izing the tMOVCC instructions.
llvm-svn: 134197
|
|
|
|
|
|
|
|
| |
It's just a t2LDMIA_UPD instruction with extra codegen properties, so it
doesn't need the encoding information. As a side-benefit, we now correctly
recognize for instruction printing as a 'pop' instruction.
llvm-svn: 134173
|
|
|
|
| |
llvm-svn: 134068
|
|
|
|
|
|
|
| |
top level type without a specified number. This syntax isn't documented
and blocks forward progress.
llvm-svn: 133371
|
|
|
|
|
|
|
|
|
| |
for pre-2.9 bitcode files. We keep x86 unaligned loads, movnt, crc32, and the
target indep prefetch change.
As usual, updating the testsuite is a PITA.
llvm-svn: 133337
|
|
|
|
|
|
|
|
|
| |
This slightly changes the GPR allocation order on Darwin where R9 is not
a callee-saved register:
Before: %R0 %R1 %R2 %R3 %R12 %R9 %LR %R4 %R5 %R6 %R8 %R10 %R11
After: %R0 %R1 %R2 %R3 %R9 %R12 %LR %R4 %R5 %R6 %R8 %R10 %R11
llvm-svn: 133326
|
|
|
|
|
|
| |
are either unreduced or only test old syntax.
llvm-svn: 133228
|
|
|
|
|
|
| |
AnalyzeBranch.
llvm-svn: 132981
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we try to branch to them.
Before we were creating successor lists with duplicated entries. Fixing that
found a bug in isBlockOnlyReachableByFallthrough that would causes it to
return the wrong answer for
-----------
...
jne foo
jmp bar
foo:
----------
llvm-svn: 132882
|
|
|
|
|
|
| |
operands to an early clobber register. This fixes <rdar://problem/9566076>.
llvm-svn: 132738
|
|
|
|
|
|
|
|
|
| |
of reserved registers.
Use RegisterClassInfo in RABasic as well. This slightly changes som
allocation orders because RegisterClassInfo puts CSR aliases last.
llvm-svn: 132581
|
|
|
|
|
|
| |
simplified version. <rdar://problem/9298790>
llvm-svn: 131274
|
|
|
|
|
|
| |
rdar://problem/9298790
llvm-svn: 131269
|
|
|
|
|
|
| |
rdar://problem/9298790
llvm-svn: 131266
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by non-CMP expressions. The executable test case (129821) would test
this as well, if we had an "-O0 -disable-arm-fast-isel" LLVM-GCC
tester. Alas, the ARM assembly would be very difficult to check with
FileCheck.
The thumb2-cbnz.ll test is affected; it generates larger code (tst.w
vs. cmp #0), but I believe the new version is correct.
rdar://problem/9298790
llvm-svn: 131261
|
|
|
|
|
|
| |
possibly related to cbnz formation.
llvm-svn: 130977
|
|
|
|
|
|
|
|
|
|
| |
edge in some cases.
Original message:
Teach MachineCSE how to do simple cross-block CSE involving physregs. This allows, for example, eliminating duplicate cmpl's on x86. Part of rdar://problem/8259436 .
llvm-svn: 130877
|
|
|
|
| |
llvm-svn: 130867
|
|
|
|
|
|
| |
allows, for example, eliminating duplicate cmpl's on x86. Part of rdar://problem/8259436 .
llvm-svn: 130862
|
|
|
|
| |
llvm-svn: 130859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These tests all follow the same pattern:
mov r2, r0
movs r0, #0
$CMP r2, r1
it eq
moveq r0, #1
bx lr
The first 'mov' can be eliminated by rematerializing 'movs r0, #0' below the
test instruction:
$CMP r0, r1
mov.w r0, #0
it eq
moveq r0, #1
bx lr
So far, only physreg coalescing can do that. The register allocators won't yet
split live ranges just to eliminate copies. They can learn, but this particular
problem is not likely to show up in real code. It only appears because r0 is
used for both the function argument and return value.
llvm-svn: 130858
|
|
|
|
| |
llvm-svn: 130567
|