| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
and ReedSolomon. Boo...
llvm-svn: 141716
|
|
|
|
|
|
|
|
| |
ARMII::AddrModeT1_s, we need to take into account that if the frame register is
ARM::SP, then the number of bits is 8. If it's not ARM::SP, then the number of
bits is 5.
llvm-svn: 141529
|
|
|
|
|
|
| |
to appease nightly testers. Not quite there yet.
llvm-svn: 140953
|
|
|
|
|
|
|
|
| |
useful if an optimization assumes the stack has been realigned. Credit to
Eli for his assistance.
rdar://10043857
llvm-svn: 140924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This uses less memory and it reduces the complexity of sub-class
operations:
- hasSubClassEq() and friends become O(1) instead of O(N).
- getCommonSubClass() becomes O(N) instead of O(N^2).
In the future, TableGen will infer register classes. This makes it
cheap to add them.
llvm-svn: 140898
|
|
|
|
| |
llvm-svn: 139635
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Add the predicate operand to the instructions. Update the back end
accordingly where the instructions are used. Restrict the SP operands
to actually only be SP, as otherwise these break assembly parsing for the
normal instruction variants.
llvm-svn: 138445
|
|
|
|
|
|
| |
when building with assertions disabled.
llvm-svn: 137460
|
|
|
|
|
|
| |
ARM MC code from target.
llvm-svn: 135636
|
|
|
|
|
|
| |
better location welcome).
llvm-svn: 135438
|
|
|
|
|
|
|
|
|
| |
to MCRegisterInfo. Also initialize the mapping at construction time.
This patch eliminate TargetRegisterInfo from TargetAsmInfo. It's another step
towards fixing the layering violation.
llvm-svn: 135424
|
|
|
|
|
|
|
|
| |
previously explicit non-default constructors were used.
Mostly mechanical with some manual reformatting.
llvm-svn: 135390
|
|
|
|
|
|
| |
registeration and creation code into XXXMCDesc libraries.
llvm-svn: 135184
|
|
|
|
|
|
|
|
|
|
| |
Unlike Thumb1, Thumb2 does not have dedicated encodings for adjusting the
stack pointer. It can just use the normal add-register-immediate encoding
since it can use all registers as a source, not just R0-R7. The extra
instruction definitions are just duplicates of the normal instructions with
the (not well enforced) constraint that the source register was SP.
llvm-svn: 134114
|
|
|
|
| |
llvm-svn: 134030
|
|
|
|
| |
llvm-svn: 134027
|
|
|
|
|
|
|
|
| |
sink them into MC layer.
- Added MCInstrInfo, which captures the tablegen generated static data. Chang
TargetInstrInfo so it's based off MCInstrInfo.
llvm-svn: 134021
|
|
|
|
| |
llvm-svn: 133944
|
|
|
|
|
|
| |
into XXXGenRegisterInfo.inc.
llvm-svn: 133922
|
|
|
|
|
|
|
|
|
|
|
|
| |
target machine from those that are only needed by codegen. The goal is to
sink the essential target description into MC layer so we can start building
MC based tools without needing to link in the entire codegen.
First step is to refactor TargetRegisterInfo. This patch added a base class
MCRegisterInfo which TargetRegisterInfo is derived from. Changed TableGen to
separate register description from the rest of the stuff.
llvm-svn: 133782
|
|
|
|
| |
llvm-svn: 133321
|
|
|
|
|
|
| |
Patch by Richard Smith!
llvm-svn: 133220
|
|
|
|
|
|
|
|
|
|
|
| |
Also switch the return type to ArrayRef<unsigned> which works out nicely
for ARM's implementation of this function because of the clever ArrayRef
constructors.
The name change indicates that the returned allocation order may contain
reserved registers as has been the case for a while.
llvm-svn: 133216
|
|
|
|
|
|
|
|
| |
directives.
Fixes PR9826.
llvm-svn: 132317
|
|
|
|
| |
llvm-svn: 131625
|
|
|
|
|
|
| |
add instruction takes an rGPR. This fixes the last of PR8825.
llvm-svn: 131619
|
|
|
|
|
|
|
|
|
|
|
|
| |
register class inflation.
The hook will be used by the register allocator when recomputing register
classes after removing constraints.
Thumb1 code doesn't allow anything larger than tGPR, and x86 needs to ensure
that the spill size doesn't change.
llvm-svn: 130228
|
|
|
|
|
|
|
|
|
|
|
| |
Add a avoidWriteAfterWrite() target hook to identify register classes that
suffer from write-after-write hazards. For those register classes, try to avoid
writing the same register in two consecutive instructions.
This is currently disabled by default. We should not spill to avoid hazards!
The command line flag -avoid-waw-hazard can be used to enable waw avoidance.
llvm-svn: 129772
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129558
|
|
|
|
|
|
|
|
|
| |
Add an assertion to linear scan to prevent it from allocating registers outside
the register class.
<rdar://problem/9183021>
llvm-svn: 128254
|
|
|
|
| |
llvm-svn: 127175
|
|
|
|
|
|
| |
because there is no way given the constpool index to examine the actual entry: the reason is clones inserted by constant island pass, which are not tracked at all! The only connection is done during asmprinting time via magic label names which is really gross and needs to be eventually fixed.
llvm-svn: 127104
|
|
|
|
|
|
| |
and fixes here and there.
llvm-svn: 123170
|
|
|
|
|
|
|
|
| |
These functions not longer assert when passed 0, but simply return false instead.
No functional change intended.
llvm-svn: 123155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
may be called. If the entry block is empty, the insertion point iterator will be
the "end()" value. Calling ->getParent() on it (among others) causes problems.
Modify materializeFrameBaseRegister to take the machine basic block and insert
the frame base register at the beginning of that block. (It's very similar to
what the code does all ready. The only difference is that it will always insert
at the beginning of the entry block instead of after a previous materialization
of the frame base register. I doubt that that matters here.)
<rdar://problem/8782198>
llvm-svn: 122104
|
|
|
|
|
|
| |
update the opcode when necessary as well as the source register.
llvm-svn: 121346
|
|
|
|
| |
llvm-svn: 120229
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
state. Previously Thumb2 would restore sp from fp like this:
mov sp, r7
sub, sp, #4
If an interrupt is taken after the 'mov' but before the 'sub', callee-saved
registers might be clobbered by the interrupt handler. Instead, try
restoring directly from sp:
add sp, #4
Or, if necessary (with VLA, etc.) use a scratch register to compute sp and
then restore it:
sub.w r4, r7, #8
mov sp, r7
rdar://8465407
llvm-svn: 119977
|
|
|
|
| |
llvm-svn: 119904
|
|
|
|
| |
llvm-svn: 119740
|
|
|
|
| |
llvm-svn: 119604
|
|
|
|
|
|
| |
out of TargetRegisterInfo to TargetFrameInfo, which is definitely much better suitable place
llvm-svn: 119097
|
|
|
|
| |
llvm-svn: 118827
|
|
|
|
| |
llvm-svn: 118823
|
|
|
|
|
|
| |
assumptions about stack layout. Specifically, LR must be saved next to FP.
llvm-svn: 118026
|
|
|
|
|
|
|
|
| |
the LDR instructions have. This makes the literal/register forms of the
instructions explicit and allows us to assign scheduling itineraries
appropriately. rdar://8477752
llvm-svn: 117505
|
|
|
|
|
|
| |
rdar://8477752.
llvm-svn: 117419
|
|
|
|
|
|
|
|
| |
explicit about the operands. Split out the different variants into separate
instructions. This gives us the ability to, among other things, assign
different scheduling itineraries to the variants. rdar://8477752.
llvm-svn: 117409
|
|
|
|
| |
llvm-svn: 117387
|