| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
(Both used for Linux gnueabi)
No behavioral change yet (no tests need so far)
llvm-svn: 146977
|
| |
|
|
|
|
| |
likely to stay either way that discussion ends up resolving itself.
llvm-svn: 146966
|
| |
|
|
|
|
| |
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146960
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We used to rely on the *eh_sjlj_setjmp instructions to mark that a function
with setjmp/longjmp exception handling clobbers all the registers. But with
the recent reorganization of ARM EH, those eh_sjlj_setjmp instructions are
expanded away earlier, before PEI can see them to determine what registers to
save and restore. Mark the dispatchsetup instruction in the same way, since
that instruction cannot be expanded early. This also more accurately reflects
when the registers are clobbered.
llvm-svn: 146949
|
| |
|
|
|
|
|
|
|
|
| |
"mov r1, r2, lsl #0" should assemble as "mov r1, r2" even though it's
not strictly legal UAL syntax. It's a common extension and the friendly
thing to do.
rdar://10604663
llvm-svn: 146937
|
| |
|
|
|
|
|
|
| |
e.g., "vmov.i32 d4, #-118" can be assembled as "vmvn.i32 d4, #117"
rdar://10603913
llvm-svn: 146925
|
| |
|
|
|
|
| |
rdar://9932658
llvm-svn: 146921
|
| |
|
|
|
|
| |
rdar://10602276
llvm-svn: 146895
|
| |
|
|
| |
llvm-svn: 146892
|
| |
|
|
| |
llvm-svn: 146887
|
| |
|
|
| |
llvm-svn: 146885
|
| |
|
|
|
|
|
| |
There's more variation that we need to handle. Error checking will need
to be on operand predicates.
llvm-svn: 146884
|
| |
|
|
| |
llvm-svn: 146882
|
| |
|
|
|
|
|
| |
Add the new TableGen register class synthesizer feature to the release
notes.
llvm-svn: 146875
|
| |
|
|
|
|
|
|
|
| |
Use information computed while inferring new register classes to emit
accurate, table-driven implementations of getMatchingSuperRegClass().
Delete the old manual, error-prone implementations in the targets.
llvm-svn: 146873
|
| |
|
|
| |
llvm-svn: 146805
|
| |
|
|
|
|
| |
I don't think this affects anything but verbose assembly.
llvm-svn: 146787
|
| |
|
|
|
|
|
|
|
| |
The bad sorting caused a misaligned basic block when building 176.vpr in
ARM mode.
<rdar://problem/10594653>
llvm-svn: 146767
|
| |
|
|
|
|
|
|
|
|
|
| |
This adjustment is already included in the block offsets computed by
BasicBlockInfo, and adjusting again here can cause the pass to loop.
When CreateNewWater splits a basic block, OffsetIsInRange would reject
the new CPE on the next pass because of the too conservative alignment
adjustment. This caused the block to be split again, and so on.
llvm-svn: 146751
|
| |
|
|
|
|
|
|
| |
The command line option should be removed, but not until the feature has
gotten a lot of testing. The ARMConstantIslandPass tends to have subtle
bugs that only show up after a while.
llvm-svn: 146739
|
| |
|
|
| |
llvm-svn: 146714
|
| |
|
|
| |
llvm-svn: 146710
|
| |
|
|
|
|
| |
value that isn't a 32-bit value. (This is just to be safe; I don't think this actually causes any issues in practice.)
llvm-svn: 146700
|
| |
|
|
| |
llvm-svn: 146699
|
| |
|
|
| |
llvm-svn: 146691
|
| |
|
|
|
|
|
| |
The code size increase is tiny (< 0.05%) because so little code uses
16-byte constant pool entries.
llvm-svn: 146690
|
| |
|
|
| |
llvm-svn: 146686
|
| |
|
|
| |
llvm-svn: 146685
|
| |
|
|
|
|
|
|
|
|
|
| |
An aligned constant pool entry may require extra alignment padding where
the new water is created. Take that into account when computing offset.
Also consider the alignment of other constant pool entries when
splitting a basic block. Alignment padding may make it necessary to
move the split point higher.
llvm-svn: 146609
|
| |
|
|
| |
llvm-svn: 146608
|
| |
|
|
| |
llvm-svn: 146605
|
| |
|
|
|
|
| |
Add tests for w/ writeback instruction parsing and encoding.
llvm-svn: 146594
|
| |
|
|
| |
llvm-svn: 146590
|
| |
|
|
|
|
|
| |
In addition to improving the representation, this adds support for assembly
parsing of these instructions.
llvm-svn: 146588
|
| |
|
|
| |
llvm-svn: 146585
|
| |
|
|
|
|
|
|
|
|
|
| |
r0 = mov #0
r0 = moveq #1
Then the second instruction has an implicit data dependency on the first
instruction. Sadly I have yet to come up with a small test case that
demonstrate the post-ra scheduler taking advantage of this.
llvm-svn: 146583
|
| |
|
|
|
|
|
|
| |
Work in progress. Parsing for non-writeback, single spaced register lists
works now. The rest have the representations better factored, but still
need more to be able to parse properly.
llvm-svn: 146579
|
| |
|
|
| |
llvm-svn: 146575
|
| |
|
|
| |
llvm-svn: 146571
|
| |
|
|
| |
llvm-svn: 146570
|
| |
|
|
| |
llvm-svn: 146569
|
| |
|
|
| |
llvm-svn: 146568
|
| |
|
|
|
|
|
|
|
|
| |
When 'cmp rn #imm' doesn't match due to the immediate not being representable,
but 'cmn rn, #-imm' does match, use the latter in place of the former, as
it's equivalent.
rdar://10552389
llvm-svn: 146567
|
| |
|
|
| |
llvm-svn: 146566
|
| |
|
|
|
|
| |
rdar://10549683
llvm-svn: 146543
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
rdar://10549767
llvm-svn: 146520
|
| |
|
|
|
|
| |
rdar://10550269
llvm-svn: 146519
|
| |
|
|
|
|
| |
rdar://10549786
llvm-svn: 146518
|
| |
|
|
| |
llvm-svn: 146516
|