summaryrefslogtreecommitdiff
path: root/lib/Target/SystemZ/SystemZInstrInfo.cpp
Commit message (Collapse)AuthorAge
* Remove target machine caching from SystemZInstrInfo andEric Christopher2014-06-27
| | | | | | | | SystemZRegisterInfo and replace it with the subtarget as that's all they needed in the first place. Update all uses and calls accordingly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211877 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-25
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207197 91177308-0d34-0410-b5e6-96231b3b80d8
* [cleanup] Lift using directives, DEBUG_TYPE definitions, and even someChandler Carruth2014-04-22
| | | | | | | | | | | | 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... git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206838 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove some empty statementsAlp Toker2014-04-19
| | | | | | Cleanup only. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206710 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Update namespace formatting to match current guidelinesRichard Sandiford2014-03-06
| | | | | | | No functional change intended. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203103 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-02
| | | | | | Remove the old functions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202636 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix known typosAlp Toker2014-01-24
| | | | | | | Sweep the codebase for common typos. Includes some changes to visible function names that were misspelt. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200018 91177308-0d34-0410-b5e6-96231b3b80d8
* Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth2014-01-07
| | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198685 91177308-0d34-0410-b5e6-96231b3b80d8
* [weak vtables] Remove a bunch of weak vtablesJuergen Ributzka2013-11-19
| | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195064 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r194865 and r194874.Alexey Samsonov2013-11-18
| | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194997 91177308-0d34-0410-b5e6-96231b3b80d8
* [weak vtables] Remove a bunch of weak vtablesJuergen Ributzka2013-11-15
| | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194865 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Improve handling of SETCCRichard Sandiford2013-10-16
| | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192784 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Use A(G)SI when spilling the target of a constant additionRichard Sandiford2013-10-15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192681 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Add comparisons of high words and memoryRichard Sandiford2013-10-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191777 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Add comparisons of large immediates using high wordsRichard Sandiford2013-10-01
| | | | | | | | There are no corresponding patterns for small immediates because they would prevent the use of fused compare-and-branch instructions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191775 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Add immediate addition involving high wordsRichard Sandiford2013-10-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191774 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Extend test-under-mask support to high GR32sRichard Sandiford2013-10-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191773 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Allow integer AND involving high wordsRichard Sandiford2013-10-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191762 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Allow integer XOR involving high wordsRichard Sandiford2013-10-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191759 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Allow integer OR involving high wordsRichard Sandiford2013-10-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191755 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Allow integer insertions with a high-word destinationRichard Sandiford2013-10-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191753 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Add patterns to load a constant into a high word (IIHF)Richard Sandiford2013-10-01
| | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191750 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Add register zero extensions involving at least one high wordRichard Sandiford2013-10-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191746 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Add truncating high-word stores (STCH and STHH)Richard Sandiford2013-10-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191743 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Add zero-extending high-word loads (LLCH and LLHH)Richard Sandiford2013-10-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191742 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Add sign-extending high-word loads (LBH and LHH)Richard Sandiford2013-10-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191740 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Use upper words of GR64s for codegenRichard Sandiford2013-10-01
| | | | | | | | | | | | | | | 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
* [SystemZ] Rename subregs and add subreg_h32Richard Sandiford2013-09-30
| | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191659 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Rein back the use of block operationsRichard Sandiford2013-09-27
| | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191525 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Define the GR64 low-word logic instructions as pseudo aliases.Richard Sandiford2013-09-25
| | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191369 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Use subregs for 64-bit truncating storesRichard Sandiford2013-09-25
| | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191365 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Add unsigned compare-and-branch instructionsRichard Sandiford2013-09-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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190930 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Fix handling of 64-bit memcmp resultsRichard Sandiford2013-08-16
| | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188540 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Fix sign of integer memcmp resultRichard Sandiford2013-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188538 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Use CLC and IPM to implement memcmpRichard Sandiford2013-08-12
| | | | | | | | For now this is restricted to fixed-length comparisons with a length in the range [1, 256], as for memcpy() and MVC. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188163 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Optimize floating-point comparisons with zeroRichard Sandiford2013-08-07
| | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187883 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Use BRCT and BRCTG to eliminate add-&-compare sequencesRichard Sandiford2013-08-05
| | | | | | | | | | | | | | | | | 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). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187723 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Use LOAD AND TEST to eliminate comparisons against zeroRichard Sandiford2013-08-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187720 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Reuse CC results for integer comparisons with zeroRichard Sandiford2013-08-01
| | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187573 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Be more careful about inverting CC masksRichard Sandiford2013-07-31
| | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187495 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Move compare-and-branch generation even laterRichard Sandiford2013-07-31
| | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187494 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Postpone NI->RISBG conversion to convertToThreeAddress()Richard Sandiford2013-07-31
| | | | | | | | | | | | | | | | | | | | | | | r186399 aggressively used the RISBG instruction for immediate ANDs, both because it can handle some values that AND IMMEDIATE can't, and because it allows the destination register to be different from the source. I realized later while implementing the distinct-ops support that it would be better to leave the choice up to convertToThreeAddress() instead. The AND IMMEDIATE form is shorter and is less likely to be cracked. This is a problem for 32-bit ANDs because we assume that all 32-bit operations will leave the high word untouched, whereas RISBG used in this way will either clear the high word or copy it from the source register. The patch uses the z196 instruction RISBLG for this instead. This means that z10 will be restricted to NILL, NILH and NILF for 32-bit ANDs, but I think that should be OK for now. Although we're using z10 as the base architecture, the optimization work is going to be focused more on z196 and zEC12. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187492 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Rework compare and branch supportRichard Sandiford2013-07-25
| | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187116 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Add LOCR and LOCGRRichard Sandiford2013-07-25
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187113 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Use SLLK, SRLK and SRAK for codegenRichard Sandiford2013-07-19
| | | | | | | This patch uses the instructions added in r186680 for codegen. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186681 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Improve spilling of LGDR and LDGRRichard Sandiford2013-07-12
| | | | | | | | If the source of these instructions is spilled we should load the destination. If the destination is spilled we should store the source. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186147 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Remove no-op MVCsRichard Sandiford2013-07-05
| | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185705 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Remove redundant frame MMOsRichard Sandiford2013-07-05
| | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185704 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Enable the use of MVC for frame-to-frame spillsRichard Sandiford2013-07-05
| | | | | | | | | | | ...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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185701 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Fold more spillsRichard Sandiford2013-07-03
| | | | | | | | | | | | | | | | 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). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185529 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 06:11:34 +0000