| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
Encode the width operand as it encodes in the instruction, which simplifies
the disassembler and the encoder, by using the imm1_32 operand def. Add a
diagnostic for the context-sensitive constraint that the width must be in
the range [1,32-lsb].
llvm-svn: 136264
|
|
|
|
|
|
|
|
| |
Start of cleaning this up a bit. First step is to remove the encoder hook by
storing the operand as the bits it'll actually encode to so it can just be
directly used. Map it to the assembly source values 8/16/24 when we print it.
llvm-svn: 136152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first problem to fix is to stop creating synthetic *Table_gen
targets next to all of the LLVM libraries. These had no real effect as
CMake specifies that add_custom_command(OUTPUT ...) directives (what the
'tablegen(...)' stuff expands to) are implicitly added as dependencies
to all the rules in that CMakeLists.txt.
These synthetic rules started to cause problems as we started more and
more heavily using tablegen files from *subdirectories* of the one where
they were generated. Within those directories, the set of tablegen
outputs was still available and so these synthetic rules added them as
dependencies of those subdirectories. However, they were no longer
properly associated with the custom command to generate them. Most of
the time this "just worked" because something would get to the parent
directory first, and run tablegen there. Once run, the files existed and
the build proceeded happily. However, as more and more subdirectories
have started using this, the probability of this failing to happen has
increased. Recently with the MC refactorings, it became quite common for
me when touching a large enough number of targets.
To add insult to injury, several of the backends *tried* to fix this by
adding explicit dependencies back to the parent directory's tablegen
rules, but those dependencies didn't work as expected -- they weren't
forming a linear chain, they were adding another thread in the race.
This patch removes these synthetic rules completely, and adds a much
simpler function to declare explicitly that a collection of tablegen'ed
files are referenced by other libraries. From that, we can add explicit
dependencies from the smaller libraries (such as every architectures
Desc library) on this and correctly form a linear sequence. All of the
backends are updated to use it, sometimes replacing the existing attempt
at adding a dependency, sometimes adding a previously missing dependency
edge.
Please let me know if this causes any problems, but it fixes a rather
persistent and problematic source of build flakiness on our end.
llvm-svn: 136023
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the Rn register encoding for both SSAT and USAT. Update the parsing of the
shift operand to correctly handle the allowed shift types and immediate ranges
and issue meaningful diagnostics when an illegal value or shift type is
specified. Add aliases to parse an ommitted shift operand (default value of
'lsl #0').
Add tests for diagnostics and proper encoding.
llvm-svn: 135990
|
|
|
|
|
|
|
|
|
| |
The immediate is in the range 1-32, but is encoded as 0-31 in a 5-bit bitfield.
Update the representation such that we store the operand as 0-31, allowing us
to remove the encoder method and the special case handling in the disassembler.
Update the assembly parser and the instruction printer accordingly.
llvm-svn: 135823
|
|
|
|
| |
llvm-svn: 135778
|
|
|
|
|
|
| |
necessitates a lot of changes to related bits.
llvm-svn: 135722
|
|
|
|
|
|
| |
ARM MC code from target.
llvm-svn: 135636
|
|
|
|
|
|
|
|
|
|
| |
Move the shift operator and special value (32 encoded as 0 for PKHTB) handling
into the instruction printer. This cleans up a bit of the disassembler
special casing for these instructions, more easily handles not printing the
operand at all for "lsl #0" and prepares for correct asm parsing of these
operands.
llvm-svn: 135626
|
|
|
|
|
|
|
|
|
| |
The shift type is implied by the instruction (PKHBT vs. PKHTB) and so shouldn't
be also encoded as part of the shift value immediate. Otherwise we're able to
represent invalid instructions, plus it needlessly complicates the
representation. Preparatory work for asm parsing of these instructions.
llvm-svn: 135616
|
|
|
|
|
|
| |
multiple instructions with the same encoding. This resolves another conflict when bringing up the new-style disassembler.
llvm-svn: 135442
|
|
|
|
|
|
| |
Original Log: Get rid of the separate opcodes for the Darwin versions of tBL, tBLXi, and tBLXr, using pseudo-instructions to lower to the single final opcode. Update the ARM disassembler for this change.
llvm-svn: 135414
|
|
|
|
| |
llvm-svn: 135343
|
|
|
|
|
|
| |
tBLXr, using pseudo-instructions to lower to the single final opcode. Update the ARM disassembler for this change.
llvm-svn: 135319
|
|
|
|
|
|
| |
to simplify the path towards an auto-generated disassembler.
llvm-svn: 135290
|
|
|
|
|
|
| |
MSVC decorates (and distinguishes) "const" in mangler. It brought linkage error between "extern const" declarations and definitions.
llvm-svn: 135269
|
|
|
|
|
|
| |
registeration and creation code into XXXMCDesc libraries.
llvm-svn: 135184
|
|
|
|
|
|
|
| |
The ISB instruction takes an optional operand, just like DMB/DSB. Typically
only 'sy' is meaningful.
llvm-svn: 135156
|
|
|
|
| |
llvm-svn: 134024
|
|
|
|
|
|
|
|
| |
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: 132044
|
|
|
|
|
|
|
|
|
| |
target register, matching BX. I filed this bug because I was confused at first:
PR10007 - ARM branch instructions have inconsistent predicate operand placement
<http://llvm.org/bugs/show_bug.cgi?id=10007>
llvm-svn: 132041
|
|
|
|
| |
llvm-svn: 132040
|
|
|
|
|
|
|
| |
Modified the patch to .td file supplied by Jyun-Yan You. Add a test case and
modified ARMDisassemblerCore.cpp a little bit.
llvm-svn: 131859
|
|
|
|
|
|
| |
immediate operand.
llvm-svn: 131565
|
|
|
|
|
|
| |
value is zero so it does not add a NULL expr operand.
llvm-svn: 130330
|
|
|
|
| |
llvm-svn: 129837
|
|
|
|
|
|
| |
rdar://problem/9292717
llvm-svn: 129619
|
|
|
|
|
|
|
|
| |
The a bit must be encoded as 0.
rdar://problem/9292625
llvm-svn: 129618
|
|
|
|
|
|
|
|
| |
instructions
(single element or n-element structure to all lanes).
llvm-svn: 129550
|
|
|
|
|
|
| |
operations.
llvm-svn: 129531
|
|
|
|
|
|
| |
rdar://problem/9280370
llvm-svn: 129480
|
|
|
|
|
|
|
|
| |
instructions (tBcc and t2Bcc).
rdar://problem/9280470
llvm-svn: 129471
|
|
|
|
|
|
| |
rdar://problem/9279440
llvm-svn: 129469
|
|
|
|
|
|
|
|
| |
as such.
rdar://problem/9276651
llvm-svn: 129462
|
|
|
|
|
|
|
|
| |
not properly handled.
rdar://problem/9276427
llvm-svn: 129456
|
|
|
|
|
|
| |
rdar://problem/9273947
llvm-svn: 129411
|
|
|
|
|
|
|
|
|
|
| |
In addition, the base register is not rGPR, but GPR with th exception that:
if n == 15 then UNPREDICTABLE
rdar://problem/9273836
llvm-svn: 129391
|
|
|
|
|
|
| |
rdar://problem/9269047
llvm-svn: 129387
|
|
|
|
|
|
|
|
|
|
| |
its Inst{23}
be specified as '1' (add = TRUE).
Also add a utility function for Thumb2.
llvm-svn: 129377
|
|
|
|
|
|
| |
Ld/St Multiple.
llvm-svn: 129365
|
|
|
|
|
|
|
|
|
| |
Encoding T1 (tBcc)
if cond == '1110' then UNDEFINED;
rdar://problem/9268681
llvm-svn: 129325
|
|
|
|
|
|
| |
rdar://problem/9267838
llvm-svn: 129320
|
|
|
|
|
|
|
|
| |
instructions are incorrectly disassembled.
rdar://problem/9266265
llvm-svn: 129298
|
|
|
|
| |
llvm-svn: 129288
|
|
|
|
|
|
|
|
| |
them as
invalid instructions.
llvm-svn: 129286
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
disassembler API. Hooked this up to the ARM target so such tools as Darwin's
otool(1) can now print things like branch targets for example this:
blx _puts
instead of this:
blx #-36
And even print the expression encoded in the Mach-O relocation entried for
things like this:
movt r0, :upper16:((_foo-_bar)+1234)
llvm-svn: 129284
|
|
|
|
| |
llvm-svn: 129160
|
|
|
|
| |
llvm-svn: 129148
|
|
|
|
|
|
|
| |
PR9650
rdar://problem/9257565
llvm-svn: 129147
|