- Jun 30, 2011
-
-
Rafael Espindola authored
llvm-svn: 134189
-
Rafael Espindola authored
nodes. Original message: Let simplify cfg simplify bb with only debug and lifetime intrinsics. llvm-svn: 134182
-
Jim Grosbach authored
It's just a call to a special helper function. Get rid of the T2 variant entirely, as it's identical to the Thumb1 version. llvm-svn: 134178
-
Andrew Trick authored
llvm-svn: 134177
-
Jim Grosbach authored
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
-
Jim Grosbach authored
It's just a tPOP instruction with additional code-gen properties, so it doesn't need encoding information. llvm-svn: 134172
-
Rafael Espindola authored
llvm-svn: 134148
-
Jim Grosbach authored
llvm-svn: 134131
-
Jim Grosbach authored
tADDrSPi is not predicable, so we can't size-reduce a t2ADDri to it if the predicate is anything other than "always." llvm-svn: 134130
-
Evan Cheng authored
llvm-svn: 134129
-
Evan Cheng authored
be the first encoded as the first feature. It then uses the CPU name to look up features / scheduling itineray even though clients know full well the CPU name being used to query these properties. The fix is to just have the clients explictly pass the CPU name! llvm-svn: 134127
-
Joerg Sonnenberger authored
llvm-svn: 134126
-
Jakob Stoklund Olesen authored
This patch will sometimes choose live range split points next to interference instead of always splitting next to a register point. That means spill code can now appear almost anywhere, and it was necessary to fix code that didn't expect that. The difficult places were: - Between a CALL returning a value on the x87 stack and the corresponding FpPOP_RETVAL (was FpGET_ST0). Probably also near x87 inline assembly, but that didn't actually show up in testing. - Between a CALL popping arguments off the stack and the corresponding ADJCALLSTACKUP. Both are fixed now. The only place spill code can't appear is after terminators, see SplitAnalysis::getLastSplitPoint. Original commit message: Rewrite RAGreedy::splitAroundRegion, now with cool ASCII art. This function has to deal with a lot of special cases, and the old version got it wrong sometimes. In particular, it would sometimes leave multiple uses in the stack interval in a single block. That causes bad code with multiple reloads in the same basic block. The new version handles block entry and exit in a single pass. It first eliminates all the easy cases, and then goes on to create a local interval for the blocks with difficult interference. Previously, we would only create the local interval for completely isolated blocks. It can happen that the stack interval becomes completely empty because we could allocate a register in all edge bundles, and the new local intervals deal with the interference. The empty stack interval is harmless, but we need to remove a SplitKit assertion that checks for empty intervals. llvm-svn: 134125
-
Andrew Trick authored
llvm-svn: 134124
-
Eric Christopher authored
Fixes rdar://9643582 llvm-svn: 134123
-
Eric Christopher authored
care about spill values. llvm-svn: 134122
-
Eric Christopher authored
we didn't have an opcode for 64-bit constant or expressions. Fixes rdar://9692967 llvm-svn: 134121
-
Bill Wendling authored
* Rough in the compact encoding part. llvm-svn: 134119
-
Bill Wendling authored
of the encoding. llvm-svn: 134117
-
Devang Patel authored
Revert r133953 for now. llvm-svn: 134116
-
Bill Wendling authored
symbols instead. llvm-svn: 134115
-
Jim Grosbach authored
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
-
Jakob Stoklund Olesen authored
Some x86-32 calls pop values off the stack, and we need to readjust the stack pointer after the call. This happens when ADJCALLSTACKUP is eliminated. It could happen that spill code was inserted between the CALL and ADJCALLSTACKUP instructions, and we would compute wrong stack pointer offsets for those frame index references. Fix this by inserting the stack pointer adjustment immediately after the call instead of where the ADJCALLSTACKUP instruction was erased. I don't have a test case since we don't currently insert code in that position. We will soon, though. I am testing a regalloc patch that didn't work on Linux because of this. llvm-svn: 134113
-
Andrew Trick authored
llvm-svn: 134112
-
Cameron Zwarich authored
already makes the assumption, which is correct on ARM, that a type's alignment is less than its alloc size. This improves codegen with Clang (which inserts a lot of extraneous alignment specifiers) and fixes <rdar://problem/9695089>. llvm-svn: 134106
-
- Jun 29, 2011
-
-
Eric Christopher authored
Part of rdar://9643582 llvm-svn: 134095
-
Eric Christopher authored
llvm-svn: 134094
-
Rafael Espindola authored
llvm-svn: 134093
-
Jim Grosbach authored
The tSpill and tRestore instructions are just copies of the tSTRspi and tLDRspi instructions, respectively. Just use those directly instead. llvm-svn: 134092
-
Eric Christopher authored
llvm-svn: 134089
-
Eric Christopher authored
getRegForInlineAsmConstraint. Part of rdar://9643582 llvm-svn: 134088
-
Eric Christopher authored
llvm-svn: 134087
-
Eric Christopher authored
creating a few specific register classes. Part of rdar://9643582 llvm-svn: 134086
-
Eric Christopher authored
for the port. Part of rdar://9643582 llvm-svn: 134085
-
Eric Christopher authored
Part of rdar://9643582 llvm-svn: 134084
-
Eric Christopher authored
Part of rdar://9643582 llvm-svn: 134083
-
Eric Christopher authored
getRegForInlineAsmConstraint. Part of rdar://9643582 llvm-svn: 134080
-
Eric Christopher authored
via vectors. Part of rdar://9643582 llvm-svn: 134079
-
Chad Rosier authored
lifetime intrinsics" due to buildbot failures. llvm-svn: 134071
-
Jim Grosbach authored
For example, ".byte 256" would previously assert() when emitting an object file. Now it generates a diagnostic that the literal value is out of range. rdar://9686950 llvm-svn: 134069
-