This adds support for TLS data relocations and modifiers:
.quad target@dtpmod
.quad target@tprel
.quad target@dtprel
Currently exploited by the asm parser only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185394 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for all missing condition register logical
instructions and extended mnemonics to the asm parser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185387 91177308-0d34-0410-b5e6-96231b3b80d8
Create a dedicated register class for floating point condition code registers and
move FCC0 from register class CCR to the new register class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185373 91177308-0d34-0410-b5e6-96231b3b80d8
A @got reference must always result in a relocation, so that
the linker has a chance to set up the GOT entry, even if the
symbol happens to be local.
Add a PPCELFObjectWriter::ExplicitRelSym routine that enforces
a relocation to be emitted for GOT references.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185353 91177308-0d34-0410-b5e6-96231b3b80d8
The test case had a couple of FIXMEs where the instruction is in
fact already supported by the back-end. In some other case, while
the generic form of the instruction is not yet supported, a
specialized form is. This adds tests for those already supported
instructions / instruction forms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185347 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the "sync $L" instruction with operand,
and provides aliases for "lwsync" and "ptesync".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185344 91177308-0d34-0410-b5e6-96231b3b80d8
The mapping between SRS pseudo-instructions and SRS native instructions was incorrect, the correct mapping is:
srsfa -> srsib
srsea -> srsia
srsfd -> srsdb
srsed -> srsda
This fixes <rdar://problem/14214734>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185155 91177308-0d34-0410-b5e6-96231b3b80d8
algorithm when assigning EnumValues to the synthesized registers.
The current algorithm, LessRecord, uses the StringRef compare_numeric
function. This function compares strings, while handling embedded numbers.
For example, the R600 backend registers are sorted as follows:
T1
T1_W
T1_X
T1_XYZW
T1_Y
T1_Z
T2
T2_W
T2_X
T2_XYZW
T2_Y
T2_Z
In this example, the 'scaling factor' is dEnum/dN = 6 because T0, T1, T2
have an EnumValue offset of 6 from one another. However, in other parts
of the register bank, the scaling factors are different:
dEnum/dN = 5:
KC0_128_W
KC0_128_X
KC0_128_XYZW
KC0_128_Y
KC0_128_Z
KC0_129_W
KC0_129_X
KC0_129_XYZW
KC0_129_Y
KC0_129_Z
The diff lists do not work correctly because different kinds of registers have
different 'scaling factors'. This new algorithm, LessRecordRegister, tries to
enforce a scaling factor of 1. For example, the registers are now sorted as
follows:
T1
T2
T3
...
T0_W
T1_W
T2_W
...
T0_X
T1_X
T2_X
...
KC0_128_W
KC0_129_W
KC0_130_W
...
For the Mips and R600 I see a 19% and 6% reduction in size, respectively. I
did see a few small regressions, but the differences were on the order of a
few bytes (e.g., AArch64 was 16 bytes). I suspect there will be even
greater wins for targets with larger register files.
Patch reviewed by Jakob.
rdar://14006013
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185094 91177308-0d34-0410-b5e6-96231b3b80d8
function to lookup the proper tablegen'ed register enumeration. Previously,
it was using the encoded value directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185026 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately this addresses two issues (by the time I'd disentangled the logic
it wasn't worth putting it back to half-broken):
+ Coprocessor instructions should all be predicable in Thumb mode.
+ BKPT should never be predicable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184965 91177308-0d34-0410-b5e6-96231b3b80d8
The barrier instructions are only "always-execute" in ARM mode, they can quite
happily sit inside an IT block in Thumb.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184964 91177308-0d34-0410-b5e6-96231b3b80d8
The assembler currently strictly verifies that immediates for
s16imm operands are in range (-32768 ... 32767). This matches
the behaviour of the GNU assembler, with one exception: gas
allows, as a special case, operands in an extended range
(-65536 .. 65535) for the addis instruction only (and its
extended mnemonic lis).
The main reason for this seems to be to allow using unsigned
16-bit operands for lis, e.g. like lis %r1, 0xfedc.
Since this has been supported by gas for a long time, and
assembler source code seen "in the wild" actually exploits
this feature, this patch adds equivalent support to LLVM
for compatibility reasons.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184946 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, all instructions taking s16imm operands support symbolic
operands. However, for u16imm operands, we only support actual
immediate integers. This causes the assembler to reject code like
ori %r5, %r5, symbol@l
This patch changes the u16imm operand definition to likewise
accept symbolic operands. In fact, s16imm and u16imm can
share the same encoding routine, now renamed to getImm16Encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184944 91177308-0d34-0410-b5e6-96231b3b80d8
Add VK_... values and relocation types necessary to support
the @got family of modifiers. Used by the asm parser only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184860 91177308-0d34-0410-b5e6-96231b3b80d8
This adds pattern for the rldcr and rldic instructions (the last instruction
from the rotate/shift family that were missing). They are currently used
only by the asm parser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184833 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the extended subtract mnemonics to the asm parser:
subi
subis
subic
subic.
sub
sub.
subc
subc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184832 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the predicted forms of branches (+/-).
There are three cases to consider:
- Branches using a PPC::Predicate code
For these, I've added new PPC::Predicate codes corresponding
to the BO values for predicted branch forms, and updated insn
printing to print them correctly. I've also added new aliases
for the asm parser matching the new forms.
- bt/bf
I've added new aliases matching to gBC etc.
- bd(n)z variants
I've added new instruction patterns for the predicted forms.
In all cases, the new patterns are used for the asm parser only.
(The new infrastructure ought to be sufficient to allow use by
the compiler too at some point.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184754 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the bt/bf/bd(n)zt/bd(n)zf mnemonics as aliases for the
asm parser, resolving to the generic conditional patterns.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184725 91177308-0d34-0410-b5e6-96231b3b80d8
This adds instruction patterns to cover the generic forms of
the conditional branch instructions. This allows the assembler
to support the generic mnemonics.
The compiler will still generate the various specific forms
of the instruction that were already supported.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184722 91177308-0d34-0410-b5e6-96231b3b80d8
There is currently only limited support for the "absolute" variants
of branch instructions. This patch adds support for the absolute
variants of all branches that are currently otherwise supported.
This requires adding new fixup types so that the correct variant
of relocation type can be selected by the object writer.
While the compiler will continue to usually choose the relative
branch variants, this will allow the asm parser to fully support
the absolute branches, with either immediate (numerical) or
symbolic target addresses.
No change in code generation intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184721 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the bd(n)zl and bd(n)zlrl instructions.
The patterns are currently used for the asm parser only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184720 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for the conditional variants of bl.
The pattern is currently used by the asm parser only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184719 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for blrl and its conditional variants.
The patterns are (currently) used for the asm parser only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184718 91177308-0d34-0410-b5e6-96231b3b80d8
When encoded to thumb, VFP instruction and VMOV/VDUP between scalar and
core registers, must have their predicate bit to 0b1110.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184707 91177308-0d34-0410-b5e6-96231b3b80d8
In thumb1, NOP is a pseudo-instruction equivalent to mov r8, r8.
However the disassembler should not use this alias.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184703 91177308-0d34-0410-b5e6-96231b3b80d8
The GNU assembler supports (as extension to the ABI) use of PC-relative
relocations in half16 fields, which allows writing code like:
li 1, base-.
This patch adds support for those relocation types in the assembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184552 91177308-0d34-0410-b5e6-96231b3b80d8
The current code base only supports the minimum set of tls-related
relocations and @modifiers that are necessary to support compiler-
generated code. This patch extends this to the full set defined
in the ABI (and supported by the GNU assembler) for the benefit
of the assembler parser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184551 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the @higher, @highera, @highest, and @highesta
modifers, including some missing relocation types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184550 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the relocation type and other necessary infrastructure
to use the @toc@h modifier in the assembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184549 91177308-0d34-0410-b5e6-96231b3b80d8
This adds necessary infrastructure to support the @h modifier.
Note that all required relocation types were already present
(and unused).
This patch provides support for using @h in the assembler;
it would also be possible to now use this feature in code
generated by the compiler, but this is not done yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184548 91177308-0d34-0410-b5e6-96231b3b80d8
This is a bit tricky as the xacquire and xrelease hints use the same bytes,
0xf2 and 0xf3, as the repne and rep prefixes.
Fortunately llvm has different llvm MCInst Opcode enums for rep/xrelease
and repne/xacquire. So to make this work a boolean was added the
InternalInstruction struct as part of the Prefix state which is set with the
added logic in readPrefixes() when decoding an instruction to determine
if these prefix bytes are to be disassembled as xacquire or xrelease. Then
we let the matcher pick the normal prefix instructionID and we change the
Opcode after that when it is set into the MCInst being created.
rdar://11019859
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184490 91177308-0d34-0410-b5e6-96231b3b80d8
The cdp2 instruction should have the same restrictions as cdp on the
co-processor registers.
VFP instructions on v8/AArch32 share the same encoding space as cdp2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184445 91177308-0d34-0410-b5e6-96231b3b80d8
The assembler parser common code supports recognizing symbol variants
using the @ modifer. On PowerPC, it should also be possible to use
(some of) those modifiers with directional labels, like "1f@l".
This patch adds support for accepting symbol variants on directional
labels as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184437 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for having the assembler optimize fixups
to constructs like "symbol@ha" or "symbol@l" if "symbol" can be
resolved at assembler time.
This optimization is already present in the PPCMCExpr.cpp code
for handling PPC_HA16/PPC_LO16 target expressions. However,
those target expression were used only on Darwin targets.
This patch changes target expression code so that they are
usable also with the GNU assembler (using the @ha / @l syntax
instead of the ha16() / lo16() syntax), and changes the
MCInst lowering code to generate those target expressions
where appropriate.
It also changes the asm parser to generate HA16/LO16 target
expressions when parsing assembler source that uses the
@ha / @l modifiers. The effect is that now the above-
mentioned optimization automatically becomes available
for those situations too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184436 91177308-0d34-0410-b5e6-96231b3b80d8
The compiler occasionally generates multiple .loc directives in a row
(at the same instruction address). These need to be transformed into
multple actual .debug_line table entries, since they are used to signal
certain information to the debugger (e.g. if the opening brace of a
function body is on the same line as the declaration).
The MCAsmStreamer version of EmitDwarfLocDirective handles this
correctly by emitting a .loc directive every time it is called.
However, the MCObjectStream version simply defaults to recording
the information and emitting only a single table entry later,
e.g. when EmitInstruction is called.
This patch introduces a MCAsmStreamer::EmitDwarfLocDirective
version that emits a line table entry for a .loc directive
that may already be pending before recording the new directive.
(This is similar to how this is handled in GNU as.)
With this patch (and the code alignment factor patch) applied,
I'm now getting identical DWARF .debug sections for all test-suite
object files on PowerPC for the internal and the external assembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184357 91177308-0d34-0410-b5e6-96231b3b80d8
"When assembling to the ARM instruction set, the .N qualifier produces
an assembler error and the .W qualifier has no effect."
In the pre-matcher handler in the asm parser the ".w" (wide) qualifier
when in ARM mode is now discarded. And an error message is now
produced when the ".n" (narrow) qualifier is used in ARM mode.
Test cases for these were added.
rdar://14064574
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184224 91177308-0d34-0410-b5e6-96231b3b80d8
When producing objects that are abi compliant we are
marking neither the object file nor the assembly file
correctly and thus generate warnings.
We need to set the EF_CPIC flag in the ELF header when
generating direct object.
Note that the warning is only generated when compiling without PIC.
When compiling with clang the warning will be suppressed by supplying:
-Wa,-mno-shared -Wa,-call_nonpic
Also the following directive should also be added:
.option pic0
when compiling without PIC, This eliminates the need for supplying:
-mno-shared -call_nonpic
on the assembler command line.
Patch by Douglas Gilmore
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184220 91177308-0d34-0410-b5e6-96231b3b80d8
For decoding, keep the current behavior of always decoding these as their REP
versions. In the future, this could be improved to recognize the cases where
these behave as XACQUIRE and XRELEASE and decode them as such.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184207 91177308-0d34-0410-b5e6-96231b3b80d8
When using a positive offset, literal loads where encoded
as if it was negative, because:
- The sign bit was not assigned to an operand
- The addrmode_imm12 operand was not encoding the sign bit correctly
This patch also makes the assembler look at the .w/.n specifier for
loads.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184182 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes two previous issues:
- Negative offsets were not correctly disassembled
- The decoded opcodes were not the right one
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184180 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-objdump should provide some way of printing out the addends present in the
.rela sections for debugging purposes if nothing else.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184072 91177308-0d34-0410-b5e6-96231b3b80d8
I've been comparing the object file output of LLVM's integrated
assembler against the external assembler on PowerPC, and one
area where differences still remain are in DWARF sections.
In particular, the GNU assembler generates .debug_frame and
.debug_line sections using a code alignment factor of 4, since
all PowerPC instructions have size 4 and must be aligned to a
multiple of 4. However, current MC code hard-codes a code
alignment factor of 1.
This patch changes this by adding a "minimum instruction alignment"
data element to MCAsmInfo and using this as code alignment factor.
This requires passing a MCContext into MCDwarfLineAddr::Encode
and MCDwarfLineAddr::EncodeAdvanceLoc. Note that one caller,
MCDwarfLineAddr::Write, didn't actually have that information
available. However, it turns out that this routine is in fact
never used in the whole code base, so the patch simply removes
it. If it turns out to be needed again at a later time, it
could be re-added with an updated interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183834 91177308-0d34-0410-b5e6-96231b3b80d8
A couple of old test cases in test/MC/PowerPC were still using
LLVM IR. Now that we have a working assembler, we can move
them to assembler tests instead:
ppc64-initial-cfa.ll
ppc64-relocs-01.ll
ppc64-tls-relocs-01.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183829 91177308-0d34-0410-b5e6-96231b3b80d8
Negative zero is returned by the primary expression parser as INT32_MIN, so all that the method needs to do is to accept this value.
Behavior already present for Thumb2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183734 91177308-0d34-0410-b5e6-96231b3b80d8
- 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?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183728 91177308-0d34-0410-b5e6-96231b3b80d8
Some ARM CPUs only support ARM mode (ancient v4 ones, for example) and some
only support Thumb mode (M-class ones currently). This makes sure such CPUs
default to the correct mode and makes the AsmParser diagnose an attempt to
switch modes incorrectly.
rdar://14024354
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183710 91177308-0d34-0410-b5e6-96231b3b80d8
A plain "sc" without argument is supposed to be treated like "sc 0"
by the assembler. This patch adds a corresponding alias.
Problem reported by Joerg Sonnenberger.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183687 91177308-0d34-0410-b5e6-96231b3b80d8
The extended branch mnemonics are supposed to use an implied CR0
if there is no explicit condition register specified. This patch
adds extra variants of the mnemonics to this effect.
Problem reported by Joerg Sonnenberger.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183686 91177308-0d34-0410-b5e6-96231b3b80d8
Changes to ARM unwind opcode assembler:
* Fix multiple .save or .vsave directives. Besides, the
order is preserved now.
* For the directives which will generate multiple opcodes,
such as ".save {r0-r11}", the order of the unwind opcode
is fixed now, i.e. the registers with less encoding value
are popped first.
* Fix the $sp offset calculation. Now, we can use the
.setfp, .pad, .save, and .vsave directives at any order.
Changes to test cases:
* Add test cases to check the order of multiple opcodes
for the .save directive.
* Fix the incorrect $sp offset in the test case. The
stack pointer offset specified in the test case was
incorrect. (Changed test cases: ehabi-mc-section.ll and
ehabi-mc.ll)
* The opcode to restore $sp are slightly reordered. The
behavior are not changed, and the new output is same
as the output of GNU as. (Changed test cases:
eh-directive-pad.s and eh-directive-setfp.s)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183627 91177308-0d34-0410-b5e6-96231b3b80d8
Handle the case when the disassembler table can't tell
the difference between some encodings of QADD and CPS.
Add some necessary safe guards in CPS decoding as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183610 91177308-0d34-0410-b5e6-96231b3b80d8
The first symbol on ELF is dummy, but it has a defined content and readelf
normally displays it. With this change llvm-readobj also displays it and we
can check that llvm-mc output is correct according to the standard.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183337 91177308-0d34-0410-b5e6-96231b3b80d8
These instructions are deprecated oddities, but we still need to be able to
disassemble (and reassemble) them if and when they're encountered.
Patch by Amaury de la Vieuville.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183011 91177308-0d34-0410-b5e6-96231b3b80d8
The disassembly of VEXT instructions was too lax in the bits checked. This
fixes the case where the instruction affects Q-registers but a misaligned lane
was specified (should be UNDEFINED).
Patch by Amaury de la Vieuville
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183003 91177308-0d34-0410-b5e6-96231b3b80d8
For COFF and MachO, sections semantically have relocations that apply to them.
That is not the case on ELF.
In relocatable objects (.o), a section with relocations in ELF has offsets to
another section where the relocations should be applied.
In dynamic objects and executables, relocations don't have an offset, they have
a virtual address. The section sh_info may or may not point to another section,
but that is not actually used for resolving the relocations.
This patch exposes that in the ObjectFile API. It has the following advantages:
* Most (all?) clients can handle this more efficiently. They will normally walk
all relocations, so doing an effort to iterate in a particular order doesn't
save time.
* llvm-readobj now prints relocations in the same way the native readelf does.
* probably most important, relocations that don't point to any section are now
visible. This is the case of relocations in the rela.dyn section. See the
updated relocation-executable.test for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182908 91177308-0d34-0410-b5e6-96231b3b80d8
This patch solves the problem of numeric register values not being accepted:
../set_alias.s:1:11: error: expected valid expression after comma
.set r4,$4
^
The parsing of .set directive is changed and handling of symbols in code
as well to enable this feature.
The test example is added.
Patch by Vladimir Medic
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182807 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for the CRJ and CGRJ instructions. Support for
the immediate forms will be a separate patch.
The architecture has a large number of comparison instructions. I think
it's generally better to concentrate on using the "best" comparison
instruction first and foremost, then only use something like CRJ if
CR really was the natual choice of comparison instruction. The patch
therefore opportunistically converts separate CR and BRC instructions
into a single CRJ while emitting instructions in ISelLowering.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182764 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, an invalid instruction like:
foo %r1, %r0
would generate the rather odd error message:
....: error: unknown token in expression
foo %r1, %r0
^
We now get the more informative:
....: error: invalid instruction
foo %r1, %r0
^
The same would happen if an address were used where a register was expected.
We now get "invalid operand for instruction" instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182644 91177308-0d34-0410-b5e6-96231b3b80d8
The idea is to make sure that:
(1) "register expected" is restricted to cases where ParseRegister()
is called and the token obviously isn't a register.
(2) "invalid register" is restricted to cases where a register-like "%..."
sequence is found, but the "..." makes no sense.
(3) the generic "invalid operand for instruction" is used in cases where
the wrong register type is used (GPR instead of FPR, etc.).
(4) the new "invalid register pair" is used if the register has the right type,
but is not a valid register pair.
Testing of (1)-(3) is now restricted to regs-bad.s. It uses a representative
instruction for each register class to make sure that only registers from
that class are accepted.
(4) is tested by both regs-bad.s (which checks all invalid register pairs)
and insn-bad.s (which tests one invalid pair for each instruction that
requires a pair).
While there, I changed "Number" to "Num" for consistency with the
operand class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182643 91177308-0d34-0410-b5e6-96231b3b80d8
Now that fixup_ppc_ha16 and fixup_ppc_lo16 are being treated exactly
the same everywhere, it no longer makes sense to have two fixup types.
This patch merges them both into a single type fixup_ppc_half16,
and renames fixup_ppc_lo16_ds to fixup_ppc_half16ds for consistency.
(The half16 and half16ds names are taken from the description of
relocation types in the PowerPC ABI.)
No change in code generation expected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182092 91177308-0d34-0410-b5e6-96231b3b80d8
The current PowerPC MC back end distinguishes between fixup_ppc_ha16
and fixup_ppc_lo16, which are determined by the instruction the fixup
applies to, and uses this distinction to decide whether a fixup ought
to resolve to the high or the low part of a symbol address.
This isn't quite correct, however. It is valid -if unusual- assembler
to use, e.g.
li 1, symbol@ha
or
lis 1, symbol@l
Whether the high or the low part of the address is used depends solely
on the @ suffix, not on the instruction.
In addition, both
li 1, symbol
and
lis 1, symbol
are valid, assuming the symbol address fits into 16 bits; again, both
will then refer to the actual symbol value (so li will load the value
itself, while lis will load the value shifted by 16).
To fix this, two places need to be adapted. If the fixup cannot be
resolved at assembler time, a relocation needs to be emitted via
PPCELFObjectWriter::getRelocType. This routine already looks at
the VK_ type to determine the relocation. The only problem is that
will reject any _LO modifier in a ha16 fixup and vice versa. This
is simply incorrect; any of those modifiers ought to be accepted
for either fixup type.
If the fixup *can* be resolved at assembler time, adjustFixupValue
currently selects the high bits of the symbol value if the fixup
type is ha16. Again, this is incorrect; see the above example
lis 1, symbol
Now, in theory we'd have to respect a VK_ modifier here. However,
in fact common code never even attempts to resolve symbol references
using any nontrivial VK_ modifier at assembler time; it will always
fall back to emitting a reloc and letting the linker handle it.
If this ever changes, presumably there'd have to be a target callback
to resolve VK_ modifiers. We'd then have to handle @ha etc. there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182091 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes alias definition for addiu $rs,$imm
and instead uses the TwoOperandAliasConstraint field in
the ArithLogicI instruction class.
This way all instructions that inherit ArithLogicI class
have the same macro defined.
The usage examples are added to test files.
Patch by Vladimir Medic
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182048 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds bnez and beqz instructions which represent alias definitions for bne and beq instructions as follows:
bnez $rs,$imm => bne $rs,$zero,$imm
beqz $rs,$imm => beq $rs,$zero,$imm
The corresponding test cases are added.
Patch by Vladimir Medic
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182040 91177308-0d34-0410-b5e6-96231b3b80d8
