| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to generate the compact unwind encoding from the machine
instructions. However, this had the problem that if the user used `-save-temps'
or compiled their hand-written `.s' file (with CFI directives), we wouldn't
generate the compact unwind encoding.
Move the algorithm that generates the compact unwind encoding into the
MCAsmBackend. This way we can generate the encoding whether the code is from a
`.ll' or `.s' file.
<rdar://problem/13623355>
llvm-svn: 190290
|
| |
|
|
| |
llvm-svn: 189728
|
| |
|
|
|
|
|
|
|
| |
Object/MachOFormat.h over to Support/MachO.h."
This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.
llvm-svn: 189321
|
| |
|
|
| |
llvm-svn: 189315
|
| |
|
|
|
|
|
|
|
|
| |
instructions. With this patch:
1. ldr.n is recognized as mnemonic for the short encoding
2. ldr.w is recognized as menmonic for the long encoding
3. ldr will map to either short or long encodings depending on the size of the offset
llvm-svn: 186831
|
| |
|
|
|
|
|
| |
assertions on win32 hosts.
FIXME: Introduce yet another checker but assert(0).
llvm-svn: 183736
|
| |
|
|
|
|
|
|
| |
- Don't use assert(0), or tests may pass or fail according to assertions.
- For now, The tests are marked as XFAIL for win32 hosts.
FIXME: Could we avoid XFAIL to specify triple in the RUN lines?
llvm-svn: 183728
|
| |
|
|
|
|
| |
FYI, isOSBinFormatCOFF() is as same as isOSWindows(), on trunk.
llvm-svn: 183727
|
| |
|
|
| |
llvm-svn: 183726
|
| |
|
|
|
|
| |
Refactor the big if/else sequence into one string switch for ARM subtype selection.
llvm-svn: 172475
|
| |
|
|
|
|
|
|
| |
cortex-m0, cortex-m3, and cortex-m4 on the backend side.
Adds new subtype values for the MachO format and use them when the related triple are set.
llvm-svn: 172472
|
| |
|
|
|
|
| |
No change in functionality.
llvm-svn: 171822
|
| |
|
|
|
|
|
|
|
|
| |
The encoding of NOP in ARMAsmBackend.cpp is missing a trailing zero, which
causes the emission of a coprocessor instruction rather than "mov r0, r0"
as indicated in the comment. The test also checks for the wrong encoding.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121203/157919.html
llvm-svn: 169420
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
| |
|
|
|
|
| |
The implementations already diverged a bit, merge them back together.
llvm-svn: 168542
|
| |
|
|
|
|
|
|
|
|
| |
The target backend can support data-in-code load commands even when
the assembler doesn't, or vice-versa. Allow targets to opt-in for
direct-to-object.
PR13973.
llvm-svn: 164974
|
| |
|
|
| |
llvm-svn: 164899
|
| |
|
|
|
|
|
|
|
| |
store this and use it to not emit long nops when the CPU is geode which
doesnt support them.
Fixes PR11212.
llvm-svn: 164132
|
| |
|
|
|
|
|
|
|
| |
for the assembler and disassembler. Which were not being set/read correctly
for offsets greater than 22 bits in some cases.
Changes to lib/Target/ARM/ARMAsmBackend.cpp from Gideon Myles!
llvm-svn: 156118
|
| |
|
|
|
|
|
|
|
|
|
| |
Replace some assert() calls w/ actual diagnostics. In a perfect world,
there'd be range checks on these values long before things ever reached
this code. For now, though, issuing a better-late-than-never diagnostic
is still a big improvement over assert().
rdar://11347287
llvm-svn: 155851
|
| |
|
|
|
|
|
|
|
|
| |
The base address for the PC-relative load is Align(PC,4), so it's the
address of the word containing the 16-bit instruction, not the address
of the instruction itself. Ugh.
rdar://11314619
llvm-svn: 155659
|
| |
|
|
|
|
|
|
| |
They reference the PC directly, so things work properly that way.
rdar://11231229
llvm-svn: 154576
|
| |
|
|
|
|
|
|
|
| |
The 8-bit payload is not contiguous in the opcode. Move the upper nibble
over 4 bits into the correct place.
rdar://11158641
llvm-svn: 153780
|
| |
|
|
|
|
|
|
| |
fixup_arm_condbranch.
Patch by Tim Northover!
llvm-svn: 153737
|
| |
|
|
| |
llvm-svn: 153502
|
| |
|
|
| |
llvm-svn: 153429
|
| |
|
|
|
|
| |
rdar://11059157
llvm-svn: 153055
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We on the linker to resolve calls to the appropriate BL/BLX instruction
to make interworking function correctly. It uses the symbol in the
relocation to do that, so we need to be careful about being too clever.
To enable this for ARM mode, split the BL/BLX fixup kind off from the
unconditional-branch fixups.
rdar://10927209
llvm-svn: 151571
|
| |
|
|
| |
llvm-svn: 148495
|
| |
|
|
| |
llvm-svn: 148456
|
| |
|
|
| |
llvm-svn: 148455
|
| |
|
|
|
|
|
|
|
| |
If the fixup is out of range for the Thumb1 instruction, relax it
to the Thumb2 encoding instead.
rdar://10711829
llvm-svn: 148424
|
| |
|
|
| |
llvm-svn: 148400
|
| |
|
|
|
|
|
|
|
|
| |
Load/store instructions w/ a fixup to be relative a function marked as thumb
don't use the low bit to specify thumb vs. non-thumb like interworking
branches do, so don't set it when dealing with those fixups.
rdar://10348687.
llvm-svn: 148366
|
| |
|
|
| |
llvm-svn: 148364
|
| |
|
|
| |
llvm-svn: 147115
|
| |
|
|
|
|
|
| |
avoid including ADT/Triple.h in many places when the target specific bits are
moved.
llvm-svn: 147059
|
| |
|
|
|
|
| |
rdar://9932658
llvm-svn: 146921
|
| |
|
|
| |
llvm-svn: 145895
|
| |
|
|
|
|
| |
rdar://10069056
llvm-svn: 145885
|
| |
|
|
|
|
|
|
| |
Whether a fixup needs relaxation for the associated instruction is a
target-specific function, as the FIXME indicated. Create a hook for that
and use it.
llvm-svn: 145881
|
| |
|
|
|
|
|
| |
Not right yet, as the rules for when to relax in the MCAssembler aren't
(yet) correct for ARM. This is a step in the proper direction, though.
llvm-svn: 145871
|
| |
|
|
|
|
|
| |
We don't (yet) have the granularity in the fixups to be specific about which
bitranges are affected. That's a future cleanup, but we're not there yet.
llvm-svn: 144852
|
| |
|
|
| |
llvm-svn: 144842
|
| |
|
|
| |
llvm-svn: 143413
|
| |
|
|
| |
llvm-svn: 140892
|
| |
|
|
|
|
|
|
|
| |
Remove an assert that was expecting only the relevant 16bit portion for
the fixup being handled. Also kill some dead code in the T2 portion.
rdar://9653509
llvm-svn: 140861
|
| |
|
|
| |
llvm-svn: 138501
|
| |
|
|
| |
llvm-svn: 138052
|
| |
|
|
|
|
|
|
|
| |
These fixups are handled poorly in general, and should have a single
contiguous range of bits per fixup type, but that's not how they're
currently organized, so for now in complex ones like for blx, we just tell the
emitter it's OK for the fixup to munge any bit it wants.
llvm-svn: 137947
|