summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/SystemZ/SystemZInstrInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [CodeGen] ArrayRef'ize cond/pred in various TII APIs. NFC.Ahmed Bougacha2015-06-111-3/+2
| | | | llvm-svn: 239553
* [InstrInfo] Refactor foldOperandImpl to thread through InsertPt. NFCKeno Fischer2015-06-081-28/+45
| | | | | | | | | | | | | | | | | | Summary: This was a longstanding FIXME and is a necessary precursor to cases where foldOperandImpl may have to create more than one instruction (e.g. to constrain a register class). This is the split out NFC changes from D6262. Reviewers: pete, ributzka, uweigand, mcrosier Reviewed By: mcrosier Subscribers: mcrosier, ted, llvm-commits Differential Revision: http://reviews.llvm.org/D10174 llvm-svn: 239336
* MachineInstr: Change return value of getOpcode() to unsigned.Matthias Braun2015-05-181-1/+1
| | | | | | | | | This was previously returning int. However there are no negative opcode numbers and more importantly this was needlessly different from MCInstrDesc::getOpcode() (which even is the value returned here) and SDValue::getOpcode()/SDNode::getOpcode(). llvm-svn: 237611
* [SystemZ] Add CodeGen support for scalar f64 ops in vector registersUlrich Weigand2015-05-051-0/+10
| | | | | | | | | | | | The z13 vector facility includes some instructions that operate only on the high f64 in a v2f64, effectively extending the FP register set from 16 to 32 registers. It's still better to use the old instructions if the operands happen to fit though, since the older instructions have a shorter encoding. Based on a patch by Richard Sandiford. llvm-svn: 236524
* [SystemZ] Add CodeGen support for integer vector typesUlrich Weigand2015-05-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This the first of a series of patches to add CodeGen support exploiting the instructions of the z13 vector facility. This patch adds support for the native integer vector types (v16i8, v8i16, v4i32, v2i64). When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level (implemented in clang), but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236521
* [SystemZ] Support RISBGN instruction on zEC12Ulrich Weigand2015-03-311-13/+21
| | | | | | | | | | | | | | So far, we do not yet support any instruction specific to zEC12. Most of the facilities added with zEC12 are indeed not very useful to compiler code generation, but there is one exception: the miscellaneous-extensions facility provides the RISBGN instruction, which is a variant of RISBG that does not set the condition code. Add support for this facility, MC support for RISBGN, and CodeGen support for prefering RISBGN over RISBG on zEC12, unless we can actually make use of the condition code set by RISBG. llvm-svn: 233690
* ArrayRefize memory operand folding. NFC.Benjamin Kramer2015-02-281-8/+7
| | | | llvm-svn: 230846
* Removing LLVM_EXPLICIT, as MSVC 2012 was the last reason for requiring the ↵Aaron Ballman2015-02-151-1/+1
| | | | | | macro. NFC; LLVM edition. llvm-svn: 229335
* [SystemZ] Make operator bool explicit. NFC.Benjamin Kramer2014-10-041-1/+1
| | | | llvm-svn: 219069
* Remove target machine caching from SystemZInstrInfo andEric Christopher2014-06-271-6/+6
| | | | | | | | SystemZRegisterInfo and replace it with the subtarget as that's all they needed in the first place. Update all uses and calls accordingly. llvm-svn: 211877
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-9/+9
| | | | llvm-svn: 207197
* [cleanup] Lift using directives, DEBUG_TYPE definitions, and even someChandler Carruth2014-04-221-2/+2
| | | | | | | | | | | | system headers above the includes of generated '.inc' files that actually contain code. In a few targets this was already done pretty consistently, but it wasn't done *really* consistently anywhere. It is strictly cleaner IMO and necessary in a bunch of places where the DEBUG_TYPE is referenced from the generated code. Consistency with the necessary places trumps. Hopefully the build bots are OK with the movement of intrin.h... llvm-svn: 206838
* Remove some empty statementsAlp Toker2014-04-191-1/+1
| | | | | | Cleanup only. llvm-svn: 206710
* [SystemZ] Update namespace formatting to match current guidelinesRichard Sandiford2014-03-061-8/+8
| | | | | | No functional change intended. llvm-svn: 203103
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-021-2/+2
| | | | | | Remove the old functions. llvm-svn: 202636
* Fix known typosAlp Toker2014-01-241-1/+1
| | | | | | | Sweep the codebase for common typos. Includes some changes to visible function names that were misspelt. llvm-svn: 200018
* Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth2014-01-071-1/+1
| | | | | | | | | | subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
* [weak vtables] Remove a bunch of weak vtablesJuergen Ributzka2013-11-191-1/+4
| | | | | | | | | | | | This patch removes most of the trivial cases of weak vtables by pinning them to a single object file. The memory leaks in this version have been fixed. Thanks Alexey for pointing them out. Differential Revision: http://llvm-reviews.chandlerc.com/D2068 Reviewed by Andy llvm-svn: 195064
* Revert r194865 and r194874.Alexey Samsonov2013-11-181-4/+1
| | | | | | | | | | | | This change is incorrect. If you delete virtual destructor of both a base class and a subclass, then the following code: Base *foo = new Child(); delete foo; will not cause the destructor for members of Child class. As a result, I observe plently of memory leaks. Notable examples I investigated are: ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl. llvm-svn: 194997
* [weak vtables] Remove a bunch of weak vtablesJuergen Ributzka2013-11-151-1/+4
| | | | | | | | | | | This patch removes most of the trivial cases of weak vtables by pinning them to a single object file. Differential Revision: http://llvm-reviews.chandlerc.com/D2068 Reviewed by Andy llvm-svn: 194865
* [SystemZ] Improve handling of SETCCRichard Sandiford2013-10-161-1/+1
| | | | | | | | We previously used the default expansion to SELECT_CC, which in turn would expand to "LHI; BRC; LHI". In most cases it's better to use an IPM-based sequence instead. llvm-svn: 192784
* [SystemZ] Use A(G)SI when spilling the target of a constant additionRichard Sandiford2013-10-151-2/+24
| | | | llvm-svn: 192681
* [SystemZ] Add comparisons of high words and memoryRichard Sandiford2013-10-011-0/+8
| | | | llvm-svn: 191777
* [SystemZ] Add comparisons of large immediates using high wordsRichard Sandiford2013-10-011-0/+8
| | | | | | | There are no corresponding patterns for small immediates because they would prevent the use of fused compare-and-branch instructions. llvm-svn: 191775
* [SystemZ] Add immediate addition involving high wordsRichard Sandiford2013-10-011-2/+50
| | | | llvm-svn: 191774
* [SystemZ] Extend test-under-mask support to high GR32sRichard Sandiford2013-10-011-0/+8
| | | | llvm-svn: 191773
* [SystemZ] Allow integer AND involving high wordsRichard Sandiford2013-10-011-33/+50
| | | | llvm-svn: 191762
* [SystemZ] Allow integer XOR involving high wordsRichard Sandiford2013-10-011-0/+4
| | | | llvm-svn: 191759
* [SystemZ] Allow integer OR involving high wordsRichard Sandiford2013-10-011-0/+12
| | | | llvm-svn: 191755
* [SystemZ] Allow integer insertions with a high-word destinationRichard Sandiford2013-10-011-0/+8
| | | | llvm-svn: 191753
* [SystemZ] Add patterns to load a constant into a high word (IIHF)Richard Sandiford2013-10-011-0/+24
| | | | | | | Similar to low words, we can use the shorter LLIHL and LLIHH if it turns out that the other half of the GR64 isn't live. llvm-svn: 191750
* [SystemZ] Add register zero extensions involving at least one high wordRichard Sandiford2013-10-011-0/+19
| | | | llvm-svn: 191746
* [SystemZ] Add truncating high-word stores (STCH and STHH)Richard Sandiford2013-10-011-0/+8
| | | | llvm-svn: 191743
* [SystemZ] Add zero-extending high-word loads (LLCH and LLHH)Richard Sandiford2013-10-011-0/+8
| | | | llvm-svn: 191742
* [SystemZ] Add sign-extending high-word loads (LBH and LHH)Richard Sandiford2013-10-011-0/+8
| | | | llvm-svn: 191740
* [SystemZ] Use upper words of GR64s for codegenRichard Sandiford2013-10-011-5/+73
| | | | | | | | | | | | | | 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. llvm-svn: 191739
* [SystemZ] Rename subregs and add subreg_h32Richard Sandiford2013-09-301-6/+6
| | | | | | | | | | | | | Use subreg_hNN and subreg_lNN for the high and low NN bits of a register. List the low registers first, so that subreg_l32 also means the low 32 bits of a 128-bit register. Floats are stored in the upper 32 bits of a 64-bit register, so they should use subreg_h32 rather than subreg_l32. No behavioral change intended. llvm-svn: 191659
* [SystemZ] Rein back the use of block operationsRichard Sandiford2013-09-271-4/+8
| | | | | | | | | | | | | | The backend tries to use block operations like MVC, NC, OC and XC for simple scalar operations. For correctness reasons, it rejects any case in which the regions might partially overlap. However, for performance reasons, it should also reject cases where the regions might be equal, since the instruction might then not use the fast path. This fixes a performance regression seen in bzip2. We may want to limit the optimisation even more in future, or even remove it entirely, but I'll try with this for now. llvm-svn: 191525
* [SystemZ] Define the GR64 low-word logic instructions as pseudo aliases.Richard Sandiford2013-09-251-6/+6
| | | | | | | | Another patch to avoid duplication of encoding information. Things like NILF, NILL and NILH are used as both 32-bit and 64-bit instructions. Here the 64-bit versions are defined as aliases of the 32-bit ones. llvm-svn: 191369
* [SystemZ] Use subregs for 64-bit truncating storesRichard Sandiford2013-09-251-1/+1
| | | | | | | | Another patch to reduce the duplication of encoding information. Rather than define separate patterns for truncating 64-bit stores, use the 32-bit stores with a subreg. No behavioral changed intended. llvm-svn: 191365
* [SystemZ] Add unsigned compare-and-branch instructionsRichard Sandiford2013-09-181-0/+18
| | | | | | | | | | | | | | | 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
* [SystemZ] Fix handling of 64-bit memcmp resultsRichard Sandiford2013-08-161-0/+7
| | | | | | | | | | | | | Generalize r188163 to cope with return types other than MVT::i32, just as the existing visitMemCmpCall code did. I've split this out into a subroutine so that it can be used for other upcoming patches. I also noticed that I'd used the wrong API to record the out chain. It's a load that uses DAG.getRoot() rather than getRoot(), so the out chain should go on PendingLoads. I don't have a testcase for that because we don't do any interesting scheduling on z yet. llvm-svn: 188540
* [SystemZ] Fix sign of integer memcmp resultRichard Sandiford2013-08-161-29/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r188163 used CLC to implement memcmp. Code that compares the result directly against zero can test the CC value produced by CLC, but code that needs an integer result must use IPM. The sequence I'd used was: ipm <reg> sll <reg>, 2 sra <reg>, 30 but I'd forgotten that this inverts the order, so that CC==1 ("less") becomes an integer greater than zero, and CC==2 ("greater") becomes an integer less than zero. This sequence should only be used if the CLC arguments are reversed to compensate. The problem then is that the branch condition must also be reversed when testing the CLC result directly. Rather than do that, I went for a different sequence that works with the natural CLC order: ipm <reg> srl <reg>, 28 rll <reg>, <reg>, 31 One advantage of this is that it doesn't clobber CC. A disadvantage is that any sign extension to 64 bits must be done separately, rather than being folded into the shifts. llvm-svn: 188538
* [SystemZ] Use CLC and IPM to implement memcmpRichard Sandiford2013-08-121-0/+93
| | | | | | | For now this is restricted to fixed-length comparisons with a length in the range [1, 256], as for memcpy() and MVC. llvm-svn: 188163
* [SystemZ] Optimize floating-point comparisons with zeroRichard Sandiford2013-08-071-0/+3
| | | | | | | | | This follows the same lines as the integer code. In the end it seemed easier to have a second 4-bit mask in TSFlags to specify the compare-like CC values. That eats one more TSFlags bit than adding a CCHasUnordered would have done, but it feels more concise. llvm-svn: 187883
* [SystemZ] Use BRCT and BRCTG to eliminate add-&-compare sequencesRichard Sandiford2013-08-051-0/+8
| | | | | | | | | | | | | | | | This patch just uses a peephole test for "add; compare; branch" sequences within a single block. The IR optimizers already convert loops to decrement-and-branch-on-nonzero form in some cases, so even this simplistic test triggers many times during a clang bootstrap and projects/test-suite run. It looks like there are still cases where we need to more strongly prefer branches on nonzero though. E.g. I saw a case where a loop that started out with a check for 0 ended up with a check for -1. I'll try to look at that sometime. I ended up adding the Reference class because MachineInstr::readsRegister() doesn't check for subregisters (by design, as far as I could tell). llvm-svn: 187723
* [SystemZ] Use LOAD AND TEST to eliminate comparisons against zeroRichard Sandiford2013-08-051-0/+13
| | | | llvm-svn: 187720
* [SystemZ] Reuse CC results for integer comparisons with zeroRichard Sandiford2013-08-011-1/+2
| | | | | | | | | | This also fixes a bug in the predication of LR to LOCR: I'd forgotten that with these in-place instruction builds, the implicit operands need to be added manually. I think this was latent until now, but is tested by int-cmp-45.c. It also adds a CC valid mask to STOC, again tested by int-cmp-45.c. llvm-svn: 187573
* [SystemZ] Be more careful about inverting CC masksRichard Sandiford2013-07-311-22/+30
| | | | | | | | | | | | | | | | | | | | | | | | System z branches have a mask to select which of the 4 CC values should cause the branch to be taken. We can invert a branch by inverting the mask. However, not all instructions can produce all 4 CC values, so inverting the branch like this can lead to some oddities. For example, integer comparisons only produce a CC of 0 (equal), 1 (less) or 2 (greater). If an integer EQ is reversed to NE before instruction selection, the branch will test for 1 or 2. If instead the branch is reversed after instruction selection (by inverting the mask), it will test for 1, 2 or 3. Both are correct, but the second isn't really canonical. This patch therefore keeps track of which CC values are possible and uses this when inverting a mask. Although this is mostly cosmestic, it fixes undefined behavior for the CIJNLH in branch-08.ll. Another fix would have been to mask out bit 0 when generating the fused compare and branch, but the point of this patch is that we shouldn't need to do that in the first place. The patch also makes it easier to reuse CC results from other instructions. llvm-svn: 187495
* [SystemZ] Move compare-and-branch generation even laterRichard Sandiford2013-07-311-103/+0
| | | | | | | | | | | | | | | | | | | | | | | r187116 moved compare-and-branch generation from the instruction-selection pass to the peephole optimizer (via optimizeCompare). It turns out that even this is a bit too early. Fused compare-and-branch instructions don't interact well with predication, where a CC result is needed. They also make it harder to reuse the CC side-effects of earlier instructions (not yet implemented, but the subject of a later patch). Another problem was that the AnalyzeBranch family of routines weren't handling compares and branches, so we weren't able to reverse the fused form in cases where we would reverse a separate branch. This could have been fixed by extending AnalyzeBranch, but given the other problems, I've instead moved the fusing to the long-branch pass, which is also responsible for the opposite transformation: splitting out-of-range compares and branches into separate compares and long branches. I've added a test for the AnalyzeBranch problem. A test for the predication problem is included in the next patch, which fixes a bug in the choice of CC mask. llvm-svn: 187494
OpenPOWER on IntegriCloud