Commit Graph

51 Commits

Author SHA1 Message Date
Richard Sandiford 45645a2c1c [SystemZ] Add MC support for interlocked-access 1 instructions
llvm-svn: 197984
2013-12-24 15:14:05 +00:00
Richard Sandiford 09de091cbe [SystemZ] Add the general form of BCR
At the moment this is just the MC support.

llvm-svn: 194585
2013-11-13 16:57:53 +00:00
Richard Sandiford b63e300b67 [SystemZ] Add comparisons of high words and memory
llvm-svn: 191777
2013-10-01 15:00:44 +00:00
Richard Sandiford a9ac0e0f75 [SystemZ] Add comparisons of large immediates using high words
There are no corresponding patterns for small immediates because they would
prevent the use of fused compare-and-branch instructions.

llvm-svn: 191775
2013-10-01 14:56:23 +00:00
Richard Sandiford 42a694f44e [SystemZ] Add immediate addition involving high words
llvm-svn: 191774
2013-10-01 14:53:46 +00:00
Richard Sandiford 5469c39a26 [SystemZ] Add truncating high-word stores (STCH and STHH)
llvm-svn: 191743
2013-10-01 12:22:49 +00:00
Richard Sandiford 0d46b1a30f [SystemZ] Add zero-extending high-word loads (LLCH and LLHH)
llvm-svn: 191742
2013-10-01 12:19:08 +00:00
Richard Sandiford 89e160d975 [SystemZ] Add sign-extending high-word loads (LBH and LHH)
llvm-svn: 191740
2013-10-01 12:11:47 +00:00
Richard Sandiford a26a4b4f60 [SystemZ] Reapply: Add definitions of LFH and STFH
Originally committed as r191661, but reverted because it changed the matching
order of comparisons on some hosts.  That should have been fixed by r191735.

llvm-svn: 191738
2013-10-01 10:31:04 +00:00
Richard Sandiford a25f268c25 [SystemZ] Revert r191661: Add definitions of LFH and STFH
For some reason, adding definitions for these load and store
instructions changed whether some of the build bots matched
comparisons as signed or unsigned.

llvm-svn: 191663
2013-09-30 12:01:35 +00:00
Richard Sandiford d30ac3a125 [SystemZ] Add definitions of LFH and STFH
llvm-svn: 191661
2013-09-30 10:50:33 +00:00
Richard Sandiford 93183ee78c [SystemZ] Add unsigned compare-and-branch instructions
For some reason I never got around to adding these at the same time as
the signed versions.  No idea why.

I'm not sure whether this SystemZII::BranchC* stuff is useful, or whether
it should just be replaced with an "is normal" flag.  I'll leave that
for later though.

There are some boundary conditions that can be tweaked, such as preferring
unsigned comparisons for equality with [128, 256), and "<= 255" over "< 256",
but again I'll leave those for a separate patch.

llvm-svn: 190930
2013-09-18 09:56:40 +00:00
Richard Sandiford a9eb9972e4 [SystemZ] Add TM and TMY
The main complication here is that TM and TMY (the memory forms) set
CC differently from the register forms.  When the tested bits contain
some 0s and some 1s, the register forms set CC to 1 or 2 based on the
value the uppermost bit.  The memory forms instead set CC to 1
regardless of the uppermost bit.

Until now, I've tried to make it so that a branch never tests for an
impossible CC value.  E.g. NR only sets CC to 0 or 1, so branches on the
result will only test for 0 or 1.  Originally I'd tried to do the same
thing for TM and TMY by using custom matching code in ISelDAGToDAG.
That ended up being very ugly though, and would have meant duplicating
some of the chain checks that the common isel code does.

I've therefore gone for the simpler alternative of adding an extra
operand to the TM DAG opcode to say whether a memory form would be OK.
This means that the inverse of a "TM;JE" is "TM;JNE" rather than the
more precise "TM;JNLE", just like the inverse of "TMLL;JE" is "TMLL;JNE".
I suppose that's arguably less confusing though...

llvm-svn: 190400
2013-09-10 10:20:32 +00:00
Richard Sandiford 178273a174 [SystemZ] Add NC, OC and XC
For now these are just used to handle scalar ANDs, ORs and XORs in which
all operands are memory.

llvm-svn: 190041
2013-09-05 10:36:45 +00:00
Richard Sandiford 35b9be298a [SystemZ] Add support for TMHH, TMHL, TMLH and TMLL
For now just handles simple comparisons of an ANDed value with zero.
The CC value provides enough information to do any comparison for a
2-bit mask, and some nonzero comparisons with more populated masks,
but that's all future work.

llvm-svn: 189469
2013-08-28 10:31:43 +00:00
Richard Sandiford 03481334b5 [SystemZ] Add basic prefetch support
Just the instructions and intrinsics for now.

llvm-svn: 189100
2013-08-23 11:36:42 +00:00
Richard Sandiford 8e92c389e4 [SystemZ] Add FI[EDX]BRA
These are extensions of the existing FI[EDX]BR instructions, but use a spare
bit to suppress inexact conditions.

llvm-svn: 188894
2013-08-21 08:58:08 +00:00
Richard Sandiford 784a580312 [SystemZ] Add negative integer absolute (load negative)
For now this matches the equivalent of (neg (abs ...)), which did hit a few
times in projects/test-suite.  We should probably also match cases where
absolute-like selects are used with reversed arguments.

llvm-svn: 188671
2013-08-19 12:56:58 +00:00
Richard Sandiford 4b89705490 [SystemZ] Add integer absolute (load positive)
llvm-svn: 188670
2013-08-19 12:48:54 +00:00
Richard Sandiford 0dec06a28c [SystemZ] Use SRST to implement strlen and strnlen
It would also make sense to use it for memchr; I'm working on that now.

llvm-svn: 188547
2013-08-16 11:41:43 +00:00
Richard Sandiford bb83a50f57 [SystemZ] Use MVST to implement strcpy and stpcpy
llvm-svn: 188546
2013-08-16 11:29:37 +00:00
Richard Sandiford ca23271010 [SystemZ] Use CLST to implement strcmp
llvm-svn: 188544
2013-08-16 11:21:54 +00:00
Daniel Dunbar 9efbedfd35 [tests] Cleanup initialization of test suffixes.
- Instead of setting the suffixes in a bunch of places, just set one master
   list in the top-level config. We now only modify the suffix list in a few
   suites that have one particular unique suffix (.ml, .mc, .yaml, .td, .py).

 - Aside from removing the need for a bunch of lit.local.cfg files, this enables
   4 tests that were inadvertently being skipped (one in
   Transforms/BranchFolding, a .s file each in DebugInfo/AArch64 and
   CodeGen/PowerPC, and one in CodeGen/SI which is now failing and has been
   XFAILED).

 - This commit also fixes a bunch of config files to use config.root instead of
   older copy-pasted code.

llvm-svn: 188513
2013-08-16 00:37:11 +00:00
Richard Sandiford 761703a248 [SystemZ] Add a definition of the CLC instruction
llvm-svn: 188162
2013-08-12 10:17:33 +00:00
Richard Sandiford 87326c73c6 [SystemZ] Add a definition of the IPM instruction
llvm-svn: 188161
2013-08-12 10:05:58 +00:00
Richard Sandiford 9f11bc1956 [SystemZ] Add floating-point load-and-test instructions
These instructions can also be used as comparisons with zero.

llvm-svn: 187882
2013-08-07 11:03:34 +00:00
Richard Sandiford 9795d8e611 [SystemZ] Add definitions for BRCT and BRCTG
llvm-svn: 187721
2013-08-05 11:07:38 +00:00
Richard Sandiford c62c64a038 [SystemZ] Add LOAD AND TEST instructions
Just the definitions and MC support.  The next patch uses them for codegen.

llvm-svn: 187719
2013-08-05 11:00:53 +00:00
Richard Sandiford 6cf80b3ec0 [SystemZ] Add RISBLG and RISBHG instruction definitions
The next patch will make use of RISBLG for codegen.

llvm-svn: 187490
2013-07-31 11:17:35 +00:00
Richard Sandiford f2404164ba [SystemZ] Add LOCR and LOCGR
llvm-svn: 187113
2013-07-25 09:11:15 +00:00
Richard Sandiford 09a8cf3604 [SystemZ] Add LOC and LOCG
As with the stores, these instructions can trap when the condition is false,
so they are only used for things like (cond ? x : *ptr).

llvm-svn: 187112
2013-07-25 09:04:52 +00:00
Richard Sandiford a68e6f5660 [SystemZ] Add STOC and STOCG
These instructions are allowed to trap even if the condition is false,
so for now they are only used for "*ptr = (cond ? x : *ptr)"-style
constructs.

llvm-svn: 187111
2013-07-25 08:57:02 +00:00
Richard Sandiford dd170bd977 [SystemZ] Add tests for ALHSIK and ALGHSIK
The insn definitions themselves crept into r186689, sorry.
This should be the last of the distinct-ops instructions.

llvm-svn: 186690
2013-07-19 16:44:32 +00:00
Richard Sandiford fac8b10a84 [SystemZ] Add ALRK, AGLRK, SLRK and SGLRK
Follows the same lines as r186686, but much more limited, since we only
use ADD LOGICAL for multi-i64 additions.

llvm-svn: 186689
2013-07-19 16:37:00 +00:00
Richard Sandiford 7d6a453623 [SystemZ] Add AHIK and AGHIK
I did these as a separate patch because it uses a slightly different
form of RIE layout.

llvm-svn: 186687
2013-07-19 16:32:12 +00:00
Richard Sandiford c575df6dcc [SystemZ] Add ARK, AGRK, SRK and SGRK
The testsuite changes follow the same lines as for r186683.

llvm-svn: 186686
2013-07-19 16:26:39 +00:00
Richard Sandiford c57e586792 [SystemZ] Add NGRK, OGRK and XGRK
Like r186683, but for 64 bits.

llvm-svn: 186685
2013-07-19 16:24:22 +00:00
Richard Sandiford 0175b4a353 [SystemZ] Add NRK, ORK and XRK
The atomic tests assume the two-operand forms, so I've restricted them to z10.

Running and-01.ll, or-01.ll and xor-01.ll for z196 as well as z10 shows why
using convertToThreeAddress() is better than exposing the three-operand forms
first and then converting back to two operands where possible (which is what
I'd originally tried).  Using the three-operand form first stops us from
taking advantage of NG, OG and XG for spills.

llvm-svn: 186683
2013-07-19 16:21:55 +00:00
Richard Sandiford 27d1cfe3d4 [SystemZ] Start adding z196 and zEC12 support
This first step just adds definitions for SLLK, SRLK and SRAK.
The next patch will actually make use of them during codegen.

insn-bad.s tests that some form of error is reported when using these
instructions on z10.  More work is needed to get the "instruction requires:
distinct-ops" that we'd ideally like, so I've stubbed that part out for now.
I'll come back and make it mandatory once the necessary changes are in.

llvm-svn: 186680
2013-07-19 16:09:03 +00:00
Richard Sandiford 35bb463fb1 [SystemZ] Add MC support for R[NOX]SBG
CodeGen support will come later.

llvm-svn: 186401
2013-07-16 11:28:08 +00:00
Richard Sandiford 67ddcd6dd0 [SystemZ] Allow 8-bit operands to RISBG
RISBG has three 8-bit operands (I3, I4 and I5).  I'd originally
restricted all three to 6 bits, since that's the only range we intended
to use at the time.  However, the top bit of I4 acts as a "zero" flag for
RISBG, while the top bit of I3 acts as a "test" flag for RNSBG & co.
This patch therefore allows them to have the full 8-bit range.
I've left the fifth operand as a 6-bit value for now since the
upper 2 bits have no defined meaning.

llvm-svn: 186070
2013-07-11 08:37:13 +00:00
Richard Sandiford 1d959008d6 [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.

llvm-svn: 185433
2013-07-02 14:56:45 +00:00
Richard Sandiford e1d9f00f09 [SystemZ] Immediate compare-and-branch support
This patch adds support for the CIJ and CGIJ instructions.

llvm-svn: 182846
2013-05-29 11:58:52 +00:00
Richard Sandiford 0fb90ab0cb [SystemZ] Register compare-and-branch support
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.

llvm-svn: 182764
2013-05-28 10:41:11 +00:00
Richard Sandiford dc5ed71353 [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.

llvm-svn: 182644
2013-05-24 14:26:46 +00:00
Richard Sandiford 675f86996a [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.

llvm-svn: 182643
2013-05-24 14:14:38 +00:00
Richard Sandiford ffd144174d [SystemZ] Make use of SUBTRACT HALFWORD
Thanks to Ulrich Weigand for noticing that this instruction was missing.

llvm-svn: 181893
2013-05-15 15:05:29 +00:00
Richard Sandiford 364d821ebc [SystemZ] Consolidate assembler tests into 4 big tests
llvm-svn: 181878
2013-05-15 09:58:19 +00:00
Richard Sandiford 18272f8490 [SystemZ] Add extra testscases for r181773
Forgot to svn add these...

llvm-svn: 181774
2013-05-14 09:49:11 +00:00
Richard Sandiford 1fb5883d77 [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.

llvm-svn: 181773
2013-05-14 09:47:26 +00:00