summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/SystemZ
Commit message (Collapse)AuthorAgeFilesLines
* [SystemZ] Rework compare and branch supportRichard Sandiford2013-07-255-62/+129
| | | | | | | | | | | | | | Before the patch we took advantage of the fact that the compare and branch are glued together in the selection DAG and fused them together (where possible) while emitting them. This seemed to work well in practice. However, fusing the compare so early makes it harder to remove redundant compares in cases where CC already has a suitable value. This patch therefore uses the peephole analyzeCompare/optimizeCompareInstr pair of functions instead. No behavioral change intended, but it paves the way for a later patch. llvm-svn: 187116
* [SystemZ] Add LOCR and LOCGRRichard Sandiford2013-07-255-0/+118
| | | | llvm-svn: 187113
* [SystemZ] Add LOC and LOCGRichard Sandiford2013-07-254-0/+75
| | | | | | | 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
* [SystemZ] Add STOC and STOCGRichard Sandiford2013-07-257-51/+126
| | | | | | | | 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
* Split generated asm mnemonic matching table into a separate table for each ↵Craig Topper2013-07-241-0/+1
| | | | | | | | 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. llvm-svn: 187026
* [SystemZ] Add ALRK, AGLRK, SLRK and SGLRKRichard Sandiford2013-07-191-4/+10
| | | | | | | Follows the same lines as r186686, but much more limited, since we only use ADD LOGICAL for multi-i64 additions. llvm-svn: 186689
* [SystemZ] Add AHIK and AGHIKRichard Sandiford2013-07-192-2/+37
| | | | | | | I did these as a separate patch because it uses a slightly different form of RIE layout. llvm-svn: 186687
* [SystemZ] Add ARK, AGRK, SRK and SGRKRichard Sandiford2013-07-191-4/+4
| | | | | | The testsuite changes follow the same lines as for r186683. llvm-svn: 186686
* [SystemZ] Add NGRK, OGRK and XGRKRichard Sandiford2013-07-192-3/+15
| | | | | | Like r186683, but for 64 bits. llvm-svn: 186685
* [SystemZ] Add NRK, ORK and XRKRichard Sandiford2013-07-192-3/+21
| | | | | | | | | | | | 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
* [SystemZ] Use SLLK, SRLK and SRAK for codegenRichard Sandiford2013-07-193-5/+73
| | | | | | This patch uses the instructions added in r186680 for codegen. llvm-svn: 186681
* [SystemZ] Start adding z196 and zEC12 supportRichard Sandiford2013-07-196-20/+58
| | | | | | | | | | | | 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
* [SystemZ] Use RNSBGRichard Sandiford2013-07-182-21/+67
| | | | | | This should be the last of the R.SBG patches for now. llvm-svn: 186573
* [SystemZ] Generalize RxSBG SRA caseRichard Sandiford2013-07-181-27/+36
| | | | | | | | | The original code only folded SRA into ROTATE ... SELECTED BITS if there was no outer shift. This patch splits out that check and generalises it slightly. The extra cases aren't really that interesting, but this is paving the way for RNSBG support. llvm-svn: 186571
* [SystemZ] Use RXSBGRichard Sandiford2013-07-181-11/+16
| | | | | | Extend the previous R.SBG patches to handle XORs. llvm-svn: 186570
* [SystemZ] Rename and formatting fixesRichard Sandiford2013-07-181-64/+61
| | | | | | | | | | | | In hindsight, using "RISBG" for something that can be any type of R.SBG instruction was a bit confusing, so this renames it to RxSBG. That might not be the best choice either, since there is an instruction called RXSBG, but hopefully the lower-case letter stands out enough. While there I fixed a couple of GNUisms that had crept in -- sorry about that! llvm-svn: 186569
* Silencing an MSVC warning about signed vs unsigned comparison mismatches.Aaron Ballman2013-07-171-1/+1
| | | | llvm-svn: 186529
* [SystemZ] Use ROSBG and non-zero form of RISBG for OR nodesRichard Sandiford2013-07-161-1/+86
| | | | llvm-svn: 186405
* [SystemZ] Add MC support for R[NOX]SBGRichard Sandiford2013-07-161-0/+8
| | | | | | CodeGen support will come later. llvm-svn: 186401
* [SystemZ] Use RISBG for (shift (and ...))Richard Sandiford2013-07-161-97/+168
| | | | | | | Another patch in the series to make more use of R.SBG. This one extends r186072 and r186073 to handle cases where the AND is inside the shift. llvm-svn: 186399
* Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector ↵Craig Topper2013-07-141-3/+3
| | | | | | size. llvm-svn: 186274
* [SystemZ] Optimize sign-extends of vector setccsRichard Sandiford2013-07-121-0/+9
| | | | | | | | | | | | | Normal (sext (setcc ...)) sequences are optimised into (select_cc ..., -1, 0) by DAGCombiner::visitSIGN_EXTEND. However, this is deliberately not done for vectors, and after vector type legalization we have (sext_inreg (setcc ...)) instead. I wondered about trying to extend DAGCombiner to handle this case too, but it seemed to be a loss on some other targets I tried, even those for which SETCC isn't "legal" and SELECT_CC is. llvm-svn: 186149
* [SystemZ] Fix parsing of inline asm registersRichard Sandiford2013-07-124-8/+49
| | | | | | | | | | | | GPR and FPR constraints like "{r2}" and "{f2}" weren't handled correctly because the name-to-regno mapping depends on the value type and (because of that) the internal names in RegStrings are not the same as the AsmName. CC constraints like "{cc}" didn't work either because there was no associated register class. llvm-svn: 186148
* [SystemZ] Improve spilling of LGDR and LDGRRichard Sandiford2013-07-121-1/+23
| | | | | | | If the source of these instructions is spilled we should load the destination. If the destination is spilled we should store the source. llvm-svn: 186147
* [SystemZ] Use zeroing form of RISBG for shift-and-AND sequencesRichard Sandiford2013-07-111-5/+66
| | | | | | Extend r186072 to handle shifts and ANDs. llvm-svn: 186073
* [SystemZ] Use zeroing form of RISBG for some AND sequencesRichard Sandiford2013-07-111-1/+118
| | | | | | | | | | | | RISBG can handle some ANDs for which no AND IMMEDIATE exists. It also acts as a three-operand AND for some cases where an AND IMMEDIATE could be used instead. It might be worth adding a pass to replace RISBG with AND IMMEDIATE in cases where the register operands end up being the same and where AND IMMEDIATE is smaller. llvm-svn: 186072
* [SystemZ] Allow 8-bit operands to RISBGRichard Sandiford2013-07-111-2/+1
| | | | | | | | | | | | 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
* AArch64/PowerPC/SystemZ/X86: This patch fixes the interface, usage, and allStephen Lin2013-07-092-3/+21
| | | | | | | | | | | | | | | | | | | | | | | in-tree implementations of TargetLoweringBase::isFMAFasterThanMulAndAdd in order to resolve the following issues with fmuladd (i.e. optional FMA) intrinsics: 1. On X86(-64) targets, ISD::FMA nodes are formed when lowering fmuladd intrinsics even if the subtarget does not support FMA instructions, leading to laughably bad code generation in some situations. 2. On AArch64 targets, ISD::FMA nodes are formed for operations on fp128, resulting in a call to a software fp128 FMA implementation. 3. On PowerPC targets, FMAs are not generated from fmuladd intrinsics on types like v2f32, v8f32, v4f64, etc., even though they promote, split, scalarize, etc. to types that support hardware FMAs. The function has also been slightly renamed for consistency and to force a merge/build conflict for any out-of-tree target implementing it. To resolve, see comments and fixed in-tree examples. llvm-svn: 185956
* [SystemZ] Use MVC for simple load/store pairsRichard Sandiford2013-07-094-0/+86
| | | | | | | | | | | | Look for patterns of the form (store (load ...), ...) in which the two locations are known not to partially overlap. (Identical locations are OK.) These sequences are better implemented by MVC unless either the load or the store could use RELATIVE LONG instructions. The testcase showed that we weren't using LHRL and LGHRL for extload16, only sextloadi16. The patch fixes that too. llvm-svn: 185919
* [SystemZ] Use "STC;MVC" for memsetRichard Sandiford2013-07-093-0/+95
| | | | | | | | | | | | Use "STC;MVC" for memsets that are too big for two STCs or MV...Is yet small enough for a single MVC. As with memcpy, I'm leaving longer cases till later. The number of tests might seem excessive, but f33 & f34 from memset-04.ll failed the first cut because I'd not added the "?:" on the calculation of Size1. llvm-svn: 185918
* [SystemZ] Remove unwanted part from last commitRichard Sandiford2013-07-081-2/+0
| | | | | | | I was originally going to use MVC for memmove too, but that's less of a clear win. Remove some accidental left-overs in the previous commit. llvm-svn: 185804
* [SystemZ] Use MVC for memcpyRichard Sandiford2013-07-089-2/+145
| | | | | | | Use MVC for memcpy in cases where a single MVC is enough. Using MVC is a win for longer copies too, but I'll leave that for later. llvm-svn: 185802
* [SystemZ] Remove no-op MVCsRichard Sandiford2013-07-052-0/+27
| | | | | | | | | | | The stack coloring pass has code to delete stores and loads that become trivially dead after coloring. Extend it to cope with single instructions that copy from one frame index to another. The testcase happens to show an example of this kicking in at the moment. It did occur in Real Code too though. llvm-svn: 185705
* [SystemZ] Remove redundant frame MMOsRichard Sandiford2013-07-051-24/+4
| | | | | | | | | | This fixes foldMemoryOperandImpl() so that it doesn't create duplicated frame MMOs. I hadn't realized when writing r185434 that it was the caller's responsibility to add these. No behavioural change intended. llvm-svn: 185704
* [SystemZ] Enable the use of MVC for frame-to-frame spillsRichard Sandiford2013-07-051-10/+2
| | | | | | | | | | ...now that the problem that prompted the restriction has been fixed. The original spill-02.py was a compromise because at the time I couldn't find an example that actually failed without the two scavenging slots. The version included here did. llvm-svn: 185701
* [SystemZ] Allocate a second register scavenging slotRichard Sandiford2013-07-051-2/+6
| | | | | | | | | | | | | This is another prerequisite for frame-to-frame MVC copies. I'll commit the patch that makes use of the slot separately. The downside of trying to test many corner cases with each of the available addressing modes is that a fair few tests need to account for the new frame layout. I do still think it's useful to have all these tests though, since it's something that wouldn't get much coverage otherwise. llvm-svn: 185698
* [SystemZ] Clean up register scavenging codeRichard Sandiford2013-07-054-57/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | SystemZ wants normal register scavenging slots, as close to the stack or frame pointer as possible. The only reason it was using custom code was because PrologEpilogInserter assumed an x86-like layout, where the frame pointer is at the opposite end of the frame from the stack pointer. This meant that when frame pointer elimination was disabled, the slots ended up being as close as possible to the incoming stack pointer, which is the opposite of what we want on SystemZ. This patch adds a new knob to say which layout is used and converts SystemZ to use target-independent scavenging slots. It's one of the pieces needed to support frame-to-frame MVCs, where two slots might be required. The ABI requires us to allocate 160 bytes for calls, so one approach would be to use that area as temporary spill space instead. It would need some surgery to make sure that the slot isn't live across a call though. I stuck to the "isFPCloseToIncomingSP - ..." style comment on the "do what the surrounding code does" principle. The FP case is already covered by several Systemz/frame-* tests, which fail without the PrologueEpilogueInserter change, so no new ones are needed. No behavioural change intended. llvm-svn: 185696
* Remove the EXCEPTIONADDR, EHSELECTION, and LSDAADDR ISD opcodes.Jakob Stoklund Olesen2013-07-041-5/+0
| | | | | | These exception-related opcodes are not used any longer. llvm-svn: 185625
* Use SmallVectorImpl::iterator/const_iterator instead of SmallVector to avoid ↵Craig Topper2013-07-041-3/+3
| | | | | | specifying the vector size. llvm-svn: 185606
* Revert r185595-185596 which broke buildbots.Jakob Stoklund Olesen2013-07-041-0/+5
| | | | | | | Revert "Simplify landing pad lowering." Revert "Remove the EXCEPTIONADDR, EHSELECTION, and LSDAADDR ISD opcodes." llvm-svn: 185600
* Remove the EXCEPTIONADDR, EHSELECTION, and LSDAADDR ISD opcodes.Jakob Stoklund Olesen2013-07-031-5/+0
| | | | | | These exception-related opcodes are not used any longer. llvm-svn: 185596
* [SystemZ] Fold more spillsRichard Sandiford2013-07-035-251/+369
| | | | | | | | | | | | | | | Add a mapping from register-based <INSN>R instructions to the corresponding memory-based <INSN>. Use it to cut down on the number of spill loads. Some instructions extend their operands from smaller fields, so this required a new TSFlags field to say how big the unextended operand is. This optimisation doesn't trigger for C(G)R and CL(G)R because in practice we always combine those instructions with a branch. Adding a test for every other case probably seems excessive, but it did catch a missed optimisation for DSGF (fixed in r185435). llvm-svn: 185529
* [SystemZ] Rename mapping table fieldsRichard Sandiford2013-07-032-37/+37
| | | | | | | | | | | | | Rename Function->DispKey and PairType->DispSize. I'd originally used "Function" because I thought it might be useful for other InstMappings. However, it turns out that having two very similar instructions with the same Function makes it pretty useless for anything other than the displacement size key. Other InstMappings will want the key to be defined for only one instruction in the pair. No behavioural change intended. llvm-svn: 185526
* [SystemZ] Fix caller-allocated save slot FIXMERichard Sandiford2013-07-033-46/+21
| | | | | | | Get rid of some old code (and associated FIXME) for handling the caller-allocated register save area. No behavioural change intended. llvm-svn: 185525
* SystemZInstrInfo.cpp: Tweak an assertion. [-Wunused-variable]NAKAMURA Takumi2013-07-031-2/+2
| | | | llvm-svn: 185499
* SystemZ: Fold variable into assertion.Benjamin Kramer2013-07-021-2/+2
| | | | llvm-svn: 185475
* Remove address spaces from MC.Rafael Espindola2013-07-021-1/+1
| | | | | | | | This is dead code since PIC16 was removed in 2010. The result was an odd mix, where some parts would carefully pass it along and others would assert it was zero (most of the object streamer for example). llvm-svn: 185436
* [SystemZ] Use DSGFR over DSGR in more casesRichard Sandiford2013-07-024-6/+12
| | | | | | | | | | Fixes some cases where we were using full 64-bit division for (sdiv i32, i32) and (sdiv i64, i32). The "32" in "SDIVREM32" just refers to the second operand. The first operand of all *DIVREM*s is a GR128. llvm-svn: 185435
* [SystemZ] Use MVC to spill loads and storesRichard Sandiford2013-07-023-13/+113
| | | | | | | | | | | | | | | | | | | | | Try to use MVC when spilling the destination of a simple load or the source of a simple store. As explained in the comment, this doesn't yet handle the case where the load or store location is also a frame index, since that could lead to two simultaneous scavenger spills, something the backend can't handle yet. spill-02.py tests that this restriction kicks in, but unfortunately I've not yet found a case that would fail without it. The volatile trick I used for other scavenger tests doesn't work here because we can't use MVC for volatile accesses anyway. I'm planning on relaxing the restriction later, hopefully with a test that does trigger the problem... Tests @f8 and @f9 also showed that L(G)RL and ST(G)RL were wrongly classified as SimpleBDX{Load,Store}. It wouldn't be easy to test for that bug separately, which is why I didn't split out the fix as a separate patch. llvm-svn: 185434
* [SystemZ] Add the MVC instructionRichard Sandiford2013-07-028-124/+243
| | | | | | | | | 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
OpenPOWER on IntegriCloud