History log of /external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
cd81d94322a39503e4a3e87b6ee03d4fcb3465fb 21-Jul-2014 Stephen Hines <srhines@google.com> Update LLVM for rebase to r212749.

Includes a cherry-pick of:
r212948 - fixes a small issue with atomic calls

Change-Id: Ib97bd980b59f18142a69506400911a6009d9df18
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
dce4a407a24b04eebc6a376f8e62b41aaa7b071f 29-May-2014 Stephen Hines <srhines@google.com> Update LLVM for 3.5 rebase (r209712).

Change-Id: I149556c940fb7dc92d075273c87ff584f400941f
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
36b56886974eae4f9c5ebc96befd3e7bfe5de338 24-Apr-2014 Stephen Hines <srhines@google.com> Update to LLVM 3.5a.

Change-Id: Ifadecab779f128e62e430c2b4f6ddd84953ed617
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
55d7d83b6c9e55fa73d667660c8e90f92999385b 01-Oct-2013 Richard Sandiford <rsandifo@linux.vnet.ibm.com> [SystemZ] Use upper words of GR64s for codegen

This just adds the basics necessary for allocating the upper words to
virtual registers (move, load and store). The move support is parameterised
in a way that makes it easy to handle zero extensions, but the associated
zero-extend patterns are added by a later patch.

The easiest way of testing this seemed to be add a new "h" register
constraint for high words. I don't expect the constraint to be useful
in real inline asms, but it should work, so I didn't try to hide it
behind an option.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191739 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
eb2f72f454048a1d179d1c75f5a953c7dfe43fc9 30-Sep-2013 Richard Sandiford <rsandifo@linux.vnet.ibm.com> [SystemZ] Add GRH32 for the high word of a GR64

The only thing this does on its own is make the definitions of RISB[HL]G
a bit more precise. Those instructions are only used by the MC layer at
the moment, so no behavioral change is intended. The class is needed by
later patches though.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191660 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
715d98d657491b3fb8ea0e14643e9801b2f9628c 12-Sep-2013 Joey Gouly <joey.gouly@arm.com> Add an instruction deprecation feature to TableGen.

The 'Deprecated' class allows you to specify a SubtargetFeature that the
instruction is deprecated on.

The 'ComplexDeprecationPredicate' class allows you to define a custom
predicate that is called to check for deprecation.
For example:
ComplexDeprecationPredicate<"MCR">

would mean you would have to define the following function:
bool getMCRDeprecationInfo(MCInst &MI, MCSubtargetInfo &STI,
std::string &Info)

Which returns 'false' for not deprecated, and 'true' for deprecated
and store the warning message in 'Info'.

The MCTargetAsmParser constructor was chaned to take an extra argument of
the MCInstrInfo class, so out-of-tree targets will need to be changed.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190598 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
f63ef914b67593e4b20a0b85e889380c20b41f55 24-Jul-2013 Craig Topper <craig.topper@gmail.com> Split generated asm mnemonic matching table into a separate table for each asm variant.

This removes the need to store the asm variant in each row of the single table that existed before. Shaves ~16K off the size of X86AsmParser.o.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187026 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
9188443a2d35352c4e8a2cffd1b4d31d47843b26 02-Jul-2013 Richard Sandiford <rsandifo@linux.vnet.ibm.com> [SystemZ] Add the MVC instruction

This is the first use of D(L,B) addressing, which required a fair bit
of surgery. For that reason, the patch just adds the instruction
definition and the associated assembler and disassembler support.
A later patch will actually make use of it for codegen.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185433 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
bfe3212dd807d018cb66479829fd81c8e7bd0f81 24-May-2013 Richard Sandiford <rsandifo@linux.vnet.ibm.com> [SystemZ] Improve AsmParser handling of invalid instructions

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
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
f386961da34426d12de8558ad04ad7f22c71489a 24-May-2013 Richard Sandiford <rsandifo@linux.vnet.ibm.com> [SystemZ] Improve AsmParser register parsing

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
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
b594c4c873bd3e2ee560cc83bd50282ec56b01e9 14-May-2013 Richard Sandiford <rsandifo@linux.vnet.ibm.com> [SystemZ] Rework handling of constant PC-relative operands

The GNU assembler treats things like:

brasl %r14, 100

in the same way as:

brasl %r14, .+100

rather than as a branch to absolute address 100. We implemented this in
LLVM by creating an immediate operand rather than the usual expr operand,
and by handling immediate operands specially in the code emitter.
This was undesirable for (at least) three reasons:

- the specialness of immediate operands was exposed to the backend MC code,
rather than being limited to the assembler parser.

- in disassembly, an immediate operand really is an absolute address.
(Note that this means reassembling printed disassembly can't recreate
the original code.)

- it would interfere with any assembly manipulation that we might
try in future. E.g. operations like branch shortening can change
the relative position of instructions, but any code that updates
sym+offset addresses wouldn't update an immediate "100" operand
in the same way as an explicit ".+100" operand.

This patch changes the implementation so that the assembler creates
a "." label for immediate PC-relative operands, so that the operand
to the MCInst is always the absolute address. The patch also adds
some error checking of the offset.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181773 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
f917bc0406e47866eb1f6c0378de16498018b620 14-May-2013 Richard Sandiford <rsandifo@linux.vnet.ibm.com> [SystemZ] Match operands to fields by name rather than by order

The SystemZ port currently relies on the order of the instruction operands
matching the order of the instruction field lists. This isn't desirable
for disassembly, where the two are matched only by name. E.g. the R1 and R2
fields of an RR instruction should have corresponding R1 and R2 operands.

The main complication is that addresses are compound operands,
and as far as I know there is no mechanism to allow individual
suboperands to be selected by name in "let Inst{...} = ..." assignments.
Luckily it doesn't really matter though. The SystemZ instruction
encoding groups all address fields together in a predictable order,
so it's just as valid to see the entire compound address operand as
a single field. That's the approach taken in this patch.

Matching by name in turn means that the operands to COPY SIGN and
CONVERT TO FIXED instructions can be given in natural order.
(It was easier to do this at the same time as the rename,
since otherwise the intermediate step was too confusing.)

No functional change intended.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181771 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
1d09d56fe1e3f3faadd4bf4ccf3e585ddb3c3b07 06-May-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [SystemZ] Add back end

This adds the actual lib/Target/SystemZ target files necessary to
implement the SystemZ target. Note that at this point, the target
cannot yet be built since the configure bits are missing. Those
will be provided shortly by a follow-on patch.

This version of the patch incorporates feedback from reviews by
Chris Lattner and Anton Korobeynikov. Thanks to all reviewers!

Patch by Richard Sandiford.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181203 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp