maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Target/SystemZ/SystemZInstrFormats.td

2459 lines
86 KiB
TableGen
Raw Normal View History

[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//==- SystemZInstrFormats.td - SystemZ Instruction Formats --*- tablegen -*-==//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//===----------------------------------------------------------------------===//
// Basic SystemZ instruction definition
//===----------------------------------------------------------------------===//
class InstSystemZ<int size, dag outs, dag ins, string asmstr,
list<dag> pattern> : Instruction {
let Namespace = "SystemZ";
dag OutOperandList = outs;
dag InOperandList = ins;
let Size = size;
let Pattern = pattern;
let AsmString = asmstr;
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
// Some instructions come in pairs, one having a 12-bit displacement
// and the other having a 20-bit displacement. Both instructions in
// the pair have the same DispKey and their DispSizes are "12" and "20"
// respectively.
string DispKey = "";
string DispSize = "none";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
// Many register-based <INSN>R instructions have a memory-based <INSN>
// counterpart. OpKey uniquely identifies <INSN>, while OpType is
// "reg" for <INSN>R and "mem" for <INSN>.
string OpKey = "";
string OpType = "none";
[SystemZ] Use SLLK, SRLK and SRAK for codegen This patch uses the instructions added in r186680 for codegen. llvm-svn: 186681
2013-07-20 00:12:08 +08:00
// Many distinct-operands instructions have older 2-operand equivalents.
// NumOpsKey uniquely identifies one of these 2-operand and 3-operand pairs,
// with NumOpsValue being "2" or "3" as appropriate.
string NumOpsKey = "";
string NumOpsValue = "none";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
// True if this instruction is a simple D(X,B) load of a register
// (with no sign or zero extension).
bit SimpleBDXLoad = 0;
// True if this instruction is a simple D(X,B) store of a register
// (with no truncation).
bit SimpleBDXStore = 0;
// True if this instruction has a 20-bit displacement field.
bit Has20BitOffset = 0;
// True if addresses in this instruction have an index register.
bit HasIndex = 0;
// True if this is a 128-bit pseudo instruction that combines two 64-bit
// operations.
bit Is128Bit = 0;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
// The access size of all memory operands in bytes, or 0 if not known.
bits<5> AccessBytes = 0;
[SystemZ] Reuse CC results for integer comparisons with zero 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
2013-08-01 18:39:40 +08:00
// If the instruction sets CC to a useful value, this gives the mask
// of all possible CC results. The mask has the same form as
// SystemZ::CCMASK_*.
bits<4> CCValues = 0;
[SystemZ] Optimize floating-point comparisons with zero 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
2013-08-07 19:10:06 +08:00
// The subset of CCValues that have the same meaning as they would after
// a comparison of the first operand against zero.
bits<4> CompareZeroCCMask = 0;
[SystemZ] Reuse CC results for integer comparisons with zero 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
2013-08-01 18:39:40 +08:00
// True if the instruction is conditional and if the CC mask operand
// comes first (as for BRC, etc.).
bit CCMaskFirst = 0;
// Similar, but true if the CC mask operand comes last (as for LOC, etc.).
bit CCMaskLast = 0;
// True if the instruction is the "logical" rather than "arithmetic" form,
// in cases where a distinction exists.
bit IsLogical = 0;
let TSFlags{0} = SimpleBDXLoad;
let TSFlags{1} = SimpleBDXStore;
let TSFlags{2} = Has20BitOffset;
let TSFlags{3} = HasIndex;
let TSFlags{4} = Is128Bit;
let TSFlags{9-5} = AccessBytes;
let TSFlags{13-10} = CCValues;
[SystemZ] Optimize floating-point comparisons with zero 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
2013-08-07 19:10:06 +08:00
let TSFlags{17-14} = CompareZeroCCMask;
let TSFlags{18} = CCMaskFirst;
let TSFlags{19} = CCMaskLast;
let TSFlags{20} = IsLogical;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
//===----------------------------------------------------------------------===//
// Mappings between instructions
//===----------------------------------------------------------------------===//
// Return the version of an instruction that has an unsigned 12-bit
// displacement.
def getDisp12Opcode : InstrMapping {
let FilterClass = "InstSystemZ";
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let RowFields = ["DispKey"];
let ColFields = ["DispSize"];
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let KeyCol = ["20"];
let ValueCols = [["12"]];
}
// Return the version of an instruction that has a signed 20-bit displacement.
def getDisp20Opcode : InstrMapping {
let FilterClass = "InstSystemZ";
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let RowFields = ["DispKey"];
let ColFields = ["DispSize"];
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let KeyCol = ["12"];
let ValueCols = [["20"]];
}
[SystemZ] Use SLLK, SRLK and SRAK for codegen This patch uses the instructions added in r186680 for codegen. llvm-svn: 186681
2013-07-20 00:12:08 +08:00
// Return the memory form of a register instruction.
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
def getMemOpcode : InstrMapping {
let FilterClass = "InstSystemZ";
let RowFields = ["OpKey"];
let ColFields = ["OpType"];
let KeyCol = ["reg"];
let ValueCols = [["mem"]];
}
[SystemZ] Use SLLK, SRLK and SRAK for codegen This patch uses the instructions added in r186680 for codegen. llvm-svn: 186681
2013-07-20 00:12:08 +08:00
// Return the 3-operand form of a 2-operand instruction.
def getThreeOperandOpcode : InstrMapping {
let FilterClass = "InstSystemZ";
let RowFields = ["NumOpsKey"];
let ColFields = ["NumOpsValue"];
let KeyCol = ["2"];
let ValueCols = [["3"]];
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//===----------------------------------------------------------------------===//
// Instruction formats
//===----------------------------------------------------------------------===//
//
// Formats are specified using operand field declarations of the form:
//
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
// bits<4> Rn : register input or output for operand n
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
// bits<5> Vn : vector register input or output for operand n
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
// bits<m> In : immediate value of width m for operand n
// bits<4> BDn : address operand n, which has a base and a displacement
// bits<m> XBDn : address operand n, which has an index, a base and a
// displacement
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
// bits<m> VBDn : address operand n, which has a vector index, a base and a
// displacement
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
// bits<4> Xn : index register for address operand n
// bits<4> Mn : mode value for operand n
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
// The operand numbers ("n" in the list above) follow the architecture manual.
// Assembly operands sometimes have a different order; in particular, R3 often
// is often written between operands 1 and 2.
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//
//===----------------------------------------------------------------------===//
class InstRI<bits<12> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<4, outs, ins, asmstr, pattern> {
field bits<32> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<32> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
bits<16> I2;
let Inst{31-24} = op{11-4};
let Inst{23-20} = R1;
let Inst{19-16} = op{3-0};
let Inst{15-0} = I2;
}
[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 18:41:11 +08:00
class InstRIEb<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<4> R1;
bits<4> R2;
bits<4> M3;
bits<16> RI4;
let Inst{47-40} = op{15-8};
let Inst{39-36} = R1;
let Inst{35-32} = R2;
let Inst{31-16} = RI4;
let Inst{15-12} = M3;
let Inst{11-8} = 0;
let Inst{7-0} = op{7-0};
}
[SystemZ] Immediate compare-and-branch support This patch adds support for the CIJ and CGIJ instructions. llvm-svn: 182846
2013-05-29 19:58:52 +08:00
class InstRIEc<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<4> R1;
bits<8> I2;
bits<4> M3;
bits<16> RI4;
let Inst{47-40} = op{15-8};
let Inst{39-36} = R1;
let Inst{35-32} = M3;
let Inst{31-16} = RI4;
let Inst{15-8} = I2;
let Inst{7-0} = op{7-0};
}
[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-20 00:32:12 +08:00
class InstRIEd<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<4> R1;
bits<4> R3;
bits<16> I2;
let Inst{47-40} = op{15-8};
let Inst{39-36} = R1;
let Inst{35-32} = R3;
let Inst{31-16} = I2;
let Inst{15-8} = 0;
let Inst{7-0} = op{7-0};
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class InstRIEf<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<48> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
bits<4> R2;
bits<8> I3;
bits<8> I4;
bits<8> I5;
let Inst{47-40} = op{15-8};
let Inst{39-36} = R1;
let Inst{35-32} = R2;
let Inst{31-24} = I3;
let Inst{23-16} = I4;
let Inst{15-8} = I5;
let Inst{7-0} = op{7-0};
}
class InstRIL<bits<12> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<48> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
bits<32> I2;
let Inst{47-40} = op{11-4};
let Inst{39-36} = R1;
let Inst{35-32} = op{3-0};
let Inst{31-0} = I2;
}
class InstRR<bits<8> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<2, outs, ins, asmstr, pattern> {
field bits<16> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<16> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
bits<4> R2;
let Inst{15-8} = op;
let Inst{7-4} = R1;
let Inst{3-0} = R2;
}
class InstRRD<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<4, outs, ins, asmstr, pattern> {
field bits<32> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<32> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
bits<4> R3;
bits<4> R2;
let Inst{31-16} = op;
let Inst{15-12} = R1;
let Inst{11-8} = 0;
let Inst{7-4} = R3;
let Inst{3-0} = R2;
}
class InstRRE<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<4, outs, ins, asmstr, pattern> {
field bits<32> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<32> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
bits<4> R2;
let Inst{31-16} = op;
let Inst{15-8} = 0;
let Inst{7-4} = R1;
let Inst{3-0} = R2;
}
class InstRRF<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<4, outs, ins, asmstr, pattern> {
field bits<32> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<32> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
bits<4> R2;
bits<4> R3;
[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 16:58:08 +08:00
bits<4> R4;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{31-16} = op;
let Inst{15-12} = R3;
[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 16:58:08 +08:00
let Inst{11-8} = R4;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{7-4} = R1;
let Inst{3-0} = R2;
}
class InstRX<bits<8> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<4, outs, ins, asmstr, pattern> {
field bits<32> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<32> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
bits<20> XBD2;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{31-24} = op;
let Inst{23-20} = R1;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Inst{19-0} = XBD2;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let HasIndex = 1;
}
class InstRXE<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<48> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
bits<20> XBD2;
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
bits<4> M3;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{47-40} = op{15-8};
let Inst{39-36} = R1;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Inst{35-16} = XBD2;
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
let Inst{15-12} = M3;
let Inst{11-8} = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{7-0} = op{7-0};
let HasIndex = 1;
}
class InstRXF<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<48> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
bits<4> R3;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
bits<20> XBD2;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{47-40} = op{15-8};
let Inst{39-36} = R3;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Inst{35-16} = XBD2;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{15-12} = R1;
let Inst{11-8} = 0;
let Inst{7-0} = op{7-0};
let HasIndex = 1;
}
class InstRXY<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<48> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
bits<28> XBD2;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{47-40} = op{15-8};
let Inst{39-36} = R1;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Inst{35-8} = XBD2;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{7-0} = op{7-0};
let Has20BitOffset = 1;
let HasIndex = 1;
}
class InstRS<bits<8> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<4, outs, ins, asmstr, pattern> {
field bits<32> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<32> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
bits<4> R3;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
bits<16> BD2;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{31-24} = op;
let Inst{23-20} = R1;
let Inst{19-16} = R3;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Inst{15-0} = BD2;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
class InstRSY<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<48> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<4> R1;
bits<4> R3;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
bits<24> BD2;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{47-40} = op{15-8};
let Inst{39-36} = R1;
let Inst{35-32} = R3;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Inst{31-8} = BD2;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{7-0} = op{7-0};
let Has20BitOffset = 1;
}
class InstSI<bits<8> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<4, outs, ins, asmstr, pattern> {
field bits<32> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<32> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
bits<16> BD1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<8> I2;
let Inst{31-24} = op;
let Inst{23-16} = I2;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Inst{15-0} = BD1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
class InstSIL<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<48> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
bits<16> BD1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<16> I2;
let Inst{47-32} = op;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Inst{31-16} = BD1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{15-0} = I2;
}
class InstSIY<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
[SystemZ] Add disassembler support llvm-svn: 181777
2013-05-14 18:17:52 +08:00
field bits<48> SoftFail = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
bits<24> BD1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bits<8> I2;
let Inst{47-40} = op{15-8};
let Inst{39-32} = I2;
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Inst{31-8} = BD1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Inst{7-0} = op{7-0};
let Has20BitOffset = 1;
}
[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 22:56:45 +08:00
class InstSS<bits<8> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<24> BDL1;
bits<16> BD2;
let Inst{47-40} = op;
let Inst{39-16} = BDL1;
let Inst{15-0} = BD2;
}
[SystemZ] Support transactional execution on zEC12 The zEC12 provides the transactional-execution facility. This is exposed to users via a set of builtin routines on other compilers. This patch adds LLVM support to enable those builtins. In partciular, the patch: - adds the transactional-execution and processor-assist facilities - adds MC support for all instructions provided by those facilities - adds LLVM intrinsics for those instructions and hooks them up for CodeGen - adds CodeGen support to optimize CC return value checking Since this is first use of target-specific intrinsics on the platform, the patch creates the include/llvm/IR/IntrinsicsSystemZ.td file and hooks it up in Intrinsics.td. I've also changed Triple::getArchTypePrefix to return "s390" instead of "systemz", since the naming convention for GCC intrinsics uses "s390" on the platform, and it neemed more straight- forward to use the same convention for LLVM IR intrinsics. An associated clang patch makes the intrinsics (and command line switches) available at the source-language level. For reference, the transactional-execution instructions are documented in the z/Architecture Principles of Operation for the zEC12: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/download/DZ9ZR009.pdf The associated builtins are documented in the GCC manual: http://gcc.gnu.org/onlinedocs/gcc/S_002f390-System-z-Built-in-Functions.html Index: llvm-head/lib/Target/SystemZ/SystemZOperators.td =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZOperators.td +++ llvm-head/lib/Target/SystemZ/SystemZOperators.td @@ -79,6 +79,9 @@ def SDT_ZI32Intrinsic : SDTypeProf def SDT_ZPrefetch : SDTypeProfile<0, 2, [SDTCisVT<0, i32>, SDTCisPtrTy<1>]>; +def SDT_ZTBegin : SDTypeProfile<0, 2, + [SDTCisPtrTy<0>, + SDTCisVT<1, i32>]>; //===----------------------------------------------------------------------===// // Node definitions @@ -180,6 +183,15 @@ def z_prefetch : SDNode<"System [SDNPHasChain, SDNPMayLoad, SDNPMayStore, SDNPMemOperand]>; +def z_tbegin : SDNode<"SystemZISD::TBEGIN", SDT_ZTBegin, + [SDNPHasChain, SDNPOutGlue, SDNPMayStore, + SDNPSideEffect]>; +def z_tbegin_nofloat : SDNode<"SystemZISD::TBEGIN_NOFLOAT", SDT_ZTBegin, + [SDNPHasChain, SDNPOutGlue, SDNPMayStore, + SDNPSideEffect]>; +def z_tend : SDNode<"SystemZISD::TEND", SDTNone, + [SDNPHasChain, SDNPOutGlue, SDNPSideEffect]>; + //===----------------------------------------------------------------------===// // Pattern fragments //===----------------------------------------------------------------------===// Index: llvm-head/lib/Target/SystemZ/SystemZInstrFormats.td =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZInstrFormats.td +++ llvm-head/lib/Target/SystemZ/SystemZInstrFormats.td @@ -473,6 +473,17 @@ class InstSS<bits<8> op, dag outs, dag i let Inst{15-0} = BD2; } +class InstS<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern> + : InstSystemZ<4, outs, ins, asmstr, pattern> { + field bits<32> Inst; + field bits<32> SoftFail = 0; + + bits<16> BD2; + + let Inst{31-16} = op; + let Inst{15-0} = BD2; +} + //===----------------------------------------------------------------------===// // Instruction definitions with semantics //===----------------------------------------------------------------------===// Index: llvm-head/lib/Target/SystemZ/SystemZInstrInfo.td =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZInstrInfo.td +++ llvm-head/lib/Target/SystemZ/SystemZInstrInfo.td @@ -1362,6 +1362,60 @@ let Defs = [CC] in { } //===----------------------------------------------------------------------===// +// Transactional execution +//===----------------------------------------------------------------------===// + +let Predicates = [FeatureTransactionalExecution] in { + // Transaction Begin + let hasSideEffects = 1, mayStore = 1, + usesCustomInserter = 1, Defs = [CC] in { + def TBEGIN : InstSIL<0xE560, + (outs), (ins bdaddr12only:$BD1, imm32zx16:$I2), + "tbegin\t$BD1, $I2", + [(z_tbegin bdaddr12only:$BD1, imm32zx16:$I2)]>; + def TBEGIN_nofloat : Pseudo<(outs), (ins bdaddr12only:$BD1, imm32zx16:$I2), + [(z_tbegin_nofloat bdaddr12only:$BD1, + imm32zx16:$I2)]>; + def TBEGINC : InstSIL<0xE561, + (outs), (ins bdaddr12only:$BD1, imm32zx16:$I2), + "tbeginc\t$BD1, $I2", + [(int_s390_tbeginc bdaddr12only:$BD1, + imm32zx16:$I2)]>; + } + + // Transaction End + let hasSideEffects = 1, Defs = [CC], BD2 = 0 in + def TEND : InstS<0xB2F8, (outs), (ins), "tend", [(z_tend)]>; + + // Transaction Abort + let hasSideEffects = 1, isTerminator = 1, isBarrier = 1 in + def TABORT : InstS<0xB2FC, (outs), (ins bdaddr12only:$BD2), + "tabort\t$BD2", + [(int_s390_tabort bdaddr12only:$BD2)]>; + + // Nontransactional Store + let hasSideEffects = 1 in + def NTSTG : StoreRXY<"ntstg", 0xE325, int_s390_ntstg, GR64, 8>; + + // Extract Transaction Nesting Depth + let hasSideEffects = 1 in + def ETND : InherentRRE<"etnd", 0xB2EC, GR32, (int_s390_etnd)>; +} + +//===----------------------------------------------------------------------===// +// Processor assist +//===----------------------------------------------------------------------===// + +let Predicates = [FeatureProcessorAssist] in { + let hasSideEffects = 1, R4 = 0 in + def PPA : InstRRF<0xB2E8, (outs), (ins GR64:$R1, GR64:$R2, imm32zx4:$R3), + "ppa\t$R1, $R2, $R3", []>; + def : Pat<(int_s390_ppa_txassist GR32:$src), + (PPA (INSERT_SUBREG (i64 (IMPLICIT_DEF)), GR32:$src, subreg_l32), + 0, 1)>; +} + +//===----------------------------------------------------------------------===// // Miscellaneous Instructions. //===----------------------------------------------------------------------===// Index: llvm-head/lib/Target/SystemZ/SystemZProcessors.td =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZProcessors.td +++ llvm-head/lib/Target/SystemZ/SystemZProcessors.td @@ -60,6 +60,16 @@ def FeatureMiscellaneousExtensions : Sys "Assume that the miscellaneous-extensions facility is installed" >; +def FeatureTransactionalExecution : SystemZFeature< + "transactional-execution", "TransactionalExecution", + "Assume that the transactional-execution facility is installed" +>; + +def FeatureProcessorAssist : SystemZFeature< + "processor-assist", "ProcessorAssist", + "Assume that the processor-assist facility is installed" +>; + def : Processor<"generic", NoItineraries, []>; def : Processor<"z10", NoItineraries, []>; def : Processor<"z196", NoItineraries, @@ -70,4 +80,5 @@ def : Processor<"zEC12", NoItineraries, [FeatureDistinctOps, FeatureLoadStoreOnCond, FeatureHighWord, FeatureFPExtension, FeaturePopulationCount, FeatureFastSerialization, FeatureInterlockedAccess1, - FeatureMiscellaneousExtensions]>; + FeatureMiscellaneousExtensions, + FeatureTransactionalExecution, FeatureProcessorAssist]>; Index: llvm-head/lib/Target/SystemZ/SystemZSubtarget.cpp =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZSubtarget.cpp +++ llvm-head/lib/Target/SystemZ/SystemZSubtarget.cpp @@ -40,6 +40,7 @@ SystemZSubtarget::SystemZSubtarget(const HasLoadStoreOnCond(false), HasHighWord(false), HasFPExtension(false), HasPopulationCount(false), HasFastSerialization(false), HasInterlockedAccess1(false), HasMiscellaneousExtensions(false), + HasTransactionalExecution(false), HasProcessorAssist(false), TargetTriple(TT), InstrInfo(initializeSubtargetDependencies(CPU, FS)), TLInfo(TM, *this), TSInfo(*TM.getDataLayout()), FrameLowering() {} Index: llvm-head/lib/Target/SystemZ/SystemZSubtarget.h =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZSubtarget.h +++ llvm-head/lib/Target/SystemZ/SystemZSubtarget.h @@ -42,6 +42,8 @@ protected: bool HasFastSerialization; bool HasInterlockedAccess1; bool HasMiscellaneousExtensions; + bool HasTransactionalExecution; + bool HasProcessorAssist; private: Triple TargetTriple; @@ -102,6 +104,12 @@ public: return HasMiscellaneousExtensions; } + // Return true if the target has the transactional-execution facility. + bool hasTransactionalExecution() const { return HasTransactionalExecution; } + + // Return true if the target has the processor-assist facility. + bool hasProcessorAssist() const { return HasProcessorAssist; } + // Return true if GV can be accessed using LARL for reloc model RM // and code model CM. bool isPC32DBLSymbol(const GlobalValue *GV, Reloc::Model RM, Index: llvm-head/lib/Support/Triple.cpp =================================================================== --- llvm-head.orig/lib/Support/Triple.cpp +++ llvm-head/lib/Support/Triple.cpp @@ -92,7 +92,7 @@ const char *Triple::getArchTypePrefix(Ar case sparcv9: case sparc: return "sparc"; - case systemz: return "systemz"; + case systemz: return "s390"; case x86: case x86_64: return "x86"; Index: llvm-head/include/llvm/IR/Intrinsics.td =================================================================== --- llvm-head.orig/include/llvm/IR/Intrinsics.td +++ llvm-head/include/llvm/IR/Intrinsics.td @@ -634,3 +634,4 @@ include "llvm/IR/IntrinsicsNVVM.td" include "llvm/IR/IntrinsicsMips.td" include "llvm/IR/IntrinsicsR600.td" include "llvm/IR/IntrinsicsBPF.td" +include "llvm/IR/IntrinsicsSystemZ.td" Index: llvm-head/include/llvm/IR/IntrinsicsSystemZ.td =================================================================== --- /dev/null +++ llvm-head/include/llvm/IR/IntrinsicsSystemZ.td @@ -0,0 +1,46 @@ +//===- IntrinsicsSystemZ.td - Defines SystemZ intrinsics ---*- tablegen -*-===// +// +// The LLVM Compiler Infrastructure +// +// This file is distributed under the University of Illinois Open Source +// License. See LICENSE.TXT for details. +// +//===----------------------------------------------------------------------===// +// +// This file defines all of the SystemZ-specific intrinsics. +// +//===----------------------------------------------------------------------===// + +//===----------------------------------------------------------------------===// +// +// Transactional-execution intrinsics +// +//===----------------------------------------------------------------------===// + +let TargetPrefix = "s390" in { + def int_s390_tbegin : Intrinsic<[llvm_i32_ty], [llvm_ptr_ty, llvm_i32_ty], + [IntrNoDuplicate]>; + + def int_s390_tbegin_nofloat : Intrinsic<[llvm_i32_ty], + [llvm_ptr_ty, llvm_i32_ty], + [IntrNoDuplicate]>; + + def int_s390_tbeginc : Intrinsic<[], [llvm_ptr_ty, llvm_i32_ty], + [IntrNoDuplicate]>; + + def int_s390_tabort : Intrinsic<[], [llvm_i64_ty], + [IntrNoReturn, Throws]>; + + def int_s390_tend : GCCBuiltin<"__builtin_tend">, + Intrinsic<[llvm_i32_ty], []>; + + def int_s390_etnd : GCCBuiltin<"__builtin_tx_nesting_depth">, + Intrinsic<[llvm_i32_ty], [], [IntrNoMem]>; + + def int_s390_ntstg : Intrinsic<[], [llvm_i64_ty, llvm_ptr64_ty], + [IntrReadWriteArgMem]>; + + def int_s390_ppa_txassist : GCCBuiltin<"__builtin_tx_assist">, + Intrinsic<[], [llvm_i32_ty]>; +} + Index: llvm-head/lib/Target/SystemZ/SystemZ.h =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZ.h +++ llvm-head/lib/Target/SystemZ/SystemZ.h @@ -68,6 +68,18 @@ const unsigned CCMASK_TM_MSB_0 = C const unsigned CCMASK_TM_MSB_1 = CCMASK_2 | CCMASK_3; const unsigned CCMASK_TM = CCMASK_ANY; +// Condition-code mask assignments for TRANSACTION_BEGIN. +const unsigned CCMASK_TBEGIN_STARTED = CCMASK_0; +const unsigned CCMASK_TBEGIN_INDETERMINATE = CCMASK_1; +const unsigned CCMASK_TBEGIN_TRANSIENT = CCMASK_2; +const unsigned CCMASK_TBEGIN_PERSISTENT = CCMASK_3; +const unsigned CCMASK_TBEGIN = CCMASK_ANY; + +// Condition-code mask assignments for TRANSACTION_END. +const unsigned CCMASK_TEND_TX = CCMASK_0; +const unsigned CCMASK_TEND_NOTX = CCMASK_2; +const unsigned CCMASK_TEND = CCMASK_TEND_TX | CCMASK_TEND_NOTX; + // The position of the low CC bit in an IPM result. const unsigned IPM_CC = 28; Index: llvm-head/lib/Target/SystemZ/SystemZISelLowering.h =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZISelLowering.h +++ llvm-head/lib/Target/SystemZ/SystemZISelLowering.h @@ -146,6 +146,15 @@ enum { // Perform a serialization operation. (BCR 15,0 or BCR 14,0.) SERIALIZE, + // Transaction begin. The first operand is the chain, the second + // the TDB pointer, and the third the immediate control field. + // Returns chain and glue. + TBEGIN, + TBEGIN_NOFLOAT, + + // Transaction end. Just the chain operand. Returns chain and glue. + TEND, + // Wrappers around the inner loop of an 8- or 16-bit ATOMIC_SWAP or // ATOMIC_LOAD_<op>. // @@ -318,6 +327,7 @@ private: SDValue lowerSTACKSAVE(SDValue Op, SelectionDAG &DAG) const; SDValue lowerSTACKRESTORE(SDValue Op, SelectionDAG &DAG) const; SDValue lowerPREFETCH(SDValue Op, SelectionDAG &DAG) const; + SDValue lowerINTRINSIC_W_CHAIN(SDValue Op, SelectionDAG &DAG) const; // If the last instruction before MBBI in MBB was some form of COMPARE, // try to replace it with a COMPARE AND BRANCH just before MBBI. @@ -355,6 +365,10 @@ private: MachineBasicBlock *emitStringWrapper(MachineInstr *MI, MachineBasicBlock *BB, unsigned Opcode) const; + MachineBasicBlock *emitTransactionBegin(MachineInstr *MI, + MachineBasicBlock *MBB, + unsigned Opcode, + bool NoFloat) const; }; } // end namespace llvm Index: llvm-head/lib/Target/SystemZ/SystemZISelLowering.cpp =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZISelLowering.cpp +++ llvm-head/lib/Target/SystemZ/SystemZISelLowering.cpp @@ -20,6 +20,7 @@ #include "llvm/CodeGen/MachineInstrBuilder.h" #include "llvm/CodeGen/MachineRegisterInfo.h" #include "llvm/CodeGen/TargetLoweringObjectFileImpl.h" +#include "llvm/IR/Intrinsics.h" #include <cctype> using namespace llvm; @@ -304,6 +305,9 @@ SystemZTargetLowering::SystemZTargetLowe // Codes for which we want to perform some z-specific combinations. setTargetDAGCombine(ISD::SIGN_EXTEND); + // Handle intrinsics. + setOperationAction(ISD::INTRINSIC_W_CHAIN, MVT::Other, Custom); + // We want to use MVC in preference to even a single load/store pair. MaxStoresPerMemcpy = 0; MaxStoresPerMemcpyOptSize = 0; @@ -1031,6 +1035,53 @@ prepareVolatileOrAtomicLoad(SDValue Chai return DAG.getNode(SystemZISD::SERIALIZE, DL, MVT::Other, Chain); } +// Return true if Op is an intrinsic node with chain that returns the CC value +// as its only (other) argument. Provide the associated SystemZISD opcode and +// the mask of valid CC values if so. +static bool isIntrinsicWithCCAndChain(SDValue Op, unsigned &Opcode, + unsigned &CCValid) { + unsigned Id = cast<ConstantSDNode>(Op.getOperand(1))->getZExtValue(); + switch (Id) { + case Intrinsic::s390_tbegin: + Opcode = SystemZISD::TBEGIN; + CCValid = SystemZ::CCMASK_TBEGIN; + return true; + + case Intrinsic::s390_tbegin_nofloat: + Opcode = SystemZISD::TBEGIN_NOFLOAT; + CCValid = SystemZ::CCMASK_TBEGIN; + return true; + + case Intrinsic::s390_tend: + Opcode = SystemZISD::TEND; + CCValid = SystemZ::CCMASK_TEND; + return true; + + default: + return false; + } +} + +// Emit an intrinsic with chain with a glued value instead of its CC result. +static SDValue emitIntrinsicWithChainAndGlue(SelectionDAG &DAG, SDValue Op, + unsigned Opcode) { + // Copy all operands except the intrinsic ID. + unsigned NumOps = Op.getNumOperands(); + SmallVector<SDValue, 6> Ops; + Ops.reserve(NumOps - 1); + Ops.push_back(Op.getOperand(0)); + for (unsigned I = 2; I < NumOps; ++I) + Ops.push_back(Op.getOperand(I)); + + assert(Op->getNumValues() == 2 && "Expected only CC result and chain"); + SDVTList RawVTs = DAG.getVTList(MVT::Other, MVT::Glue); + SDValue Intr = DAG.getNode(Opcode, SDLoc(Op), RawVTs, Ops); + SDValue OldChain = SDValue(Op.getNode(), 1); + SDValue NewChain = SDValue(Intr.getNode(), 0); + DAG.ReplaceAllUsesOfValueWith(OldChain, NewChain); + return Intr; +} + // CC is a comparison that will be implemented using an integer or // floating-point comparison. Return the condition code mask for // a branch on true. In the integer case, CCMASK_CMP_UO is set for @@ -1588,9 +1639,53 @@ static void adjustForTestUnderMask(Selec C.CCMask = NewCCMask; } +// Return a Comparison that tests the condition-code result of intrinsic +// node Call against constant integer CC using comparison code Cond. +// Opcode is the opcode of the SystemZISD operation for the intrinsic +// and CCValid is the set of possible condition-code results. +static Comparison getIntrinsicCmp(SelectionDAG &DAG, unsigned Opcode, + SDValue Call, unsigned CCValid, uint64_t CC, + ISD::CondCode Cond) { + Comparison C(Call, SDValue()); + C.Opcode = Opcode; + C.CCValid = CCValid; + if (Cond == ISD::SETEQ) + // bit 3 for CC==0, bit 0 for CC==3, always false for CC>3. + C.CCMask = CC < 4 ? 1 << (3 - CC) : 0; + else if (Cond == ISD::SETNE) + // ...and the inverse of that. + C.CCMask = CC < 4 ? ~(1 << (3 - CC)) : -1; + else if (Cond == ISD::SETLT || Cond == ISD::SETULT) + // bits above bit 3 for CC==0 (always false), bits above bit 0 for CC==3, + // always true for CC>3. + C.CCMask = CC < 4 ? -1 << (4 - CC) : -1; + else if (Cond == ISD::SETGE || Cond == ISD::SETUGE) + // ...and the inverse of that. + C.CCMask = CC < 4 ? ~(-1 << (4 - CC)) : 0; + else if (Cond == ISD::SETLE || Cond == ISD::SETULE) + // bit 3 and above for CC==0, bit 0 and above for CC==3 (always true), + // always true for CC>3. + C.CCMask = CC < 4 ? -1 << (3 - CC) : -1; + else if (Cond == ISD::SETGT || Cond == ISD::SETUGT) + // ...and the inverse of that. + C.CCMask = CC < 4 ? ~(-1 << (3 - CC)) : 0; + else + llvm_unreachable("Unexpected integer comparison type"); + C.CCMask &= CCValid; + return C; +} + // Decide how to implement a comparison of type Cond between CmpOp0 with CmpOp1. static Comparison getCmp(SelectionDAG &DAG, SDValue CmpOp0, SDValue CmpOp1, ISD::CondCode Cond) { + if (CmpOp1.getOpcode() == ISD::Constant) { + uint64_t Constant = cast<ConstantSDNode>(CmpOp1)->getZExtValue(); + unsigned Opcode, CCValid; + if (CmpOp0.getOpcode() == ISD::INTRINSIC_W_CHAIN && + CmpOp0.getResNo() == 0 && CmpOp0->hasNUsesOfValue(1, 0) && + isIntrinsicWithCCAndChain(CmpOp0, Opcode, CCValid)) + return getIntrinsicCmp(DAG, Opcode, CmpOp0, CCValid, Constant, Cond); + } Comparison C(CmpOp0, CmpOp1); C.CCMask = CCMaskForCondCode(Cond); if (C.Op0.getValueType().isFloatingPoint()) { @@ -1632,6 +1727,17 @@ static Comparison getCmp(SelectionDAG &D // Emit the comparison instruction described by C. static SDValue emitCmp(SelectionDAG &DAG, SDLoc DL, Comparison &C) { + if (!C.Op1.getNode()) { + SDValue Op; + switch (C.Op0.getOpcode()) { + case ISD::INTRINSIC_W_CHAIN: + Op = emitIntrinsicWithChainAndGlue(DAG, C.Op0, C.Opcode); + break; + default: + llvm_unreachable("Invalid comparison operands"); + } + return SDValue(Op.getNode(), Op->getNumValues() - 1); + } if (C.Opcode == SystemZISD::ICMP) return DAG.getNode(SystemZISD::ICMP, DL, MVT::Glue, C.Op0, C.Op1, DAG.getConstant(C.ICmpType, MVT::i32)); @@ -1713,7 +1819,6 @@ SDValue SystemZTargetLowering::lowerSETC } SDValue SystemZTargetLowering::lowerBR_CC(SDValue Op, SelectionDAG &DAG) const { - SDValue Chain = Op.getOperand(0); ISD::CondCode CC = cast<CondCodeSDNode>(Op.getOperand(1))->get(); SDValue CmpOp0 = Op.getOperand(2); SDValue CmpOp1 = Op.getOperand(3); @@ -1723,7 +1828,7 @@ SDValue SystemZTargetLowering::lowerBR_C Comparison C(getCmp(DAG, CmpOp0, CmpOp1, CC)); SDValue Glue = emitCmp(DAG, DL, C); return DAG.getNode(SystemZISD::BR_CCMASK, DL, Op.getValueType(), - Chain, DAG.getConstant(C.CCValid, MVT::i32), + Op.getOperand(0), DAG.getConstant(C.CCValid, MVT::i32), DAG.getConstant(C.CCMask, MVT::i32), Dest, Glue); } @@ -2561,6 +2666,30 @@ SDValue SystemZTargetLowering::lowerPREF Node->getMemoryVT(), Node->getMemOperand()); } +// Return an i32 that contains the value of CC immediately after After, +// whose final operand must be MVT::Glue. +static SDValue getCCResult(SelectionDAG &DAG, SDNode *After) { + SDValue Glue = SDValue(After, After->getNumValues() - 1); + SDValue IPM = DAG.getNode(SystemZISD::IPM, SDLoc(After), MVT::i32, Glue); + return DAG.getNode(ISD::SRL, SDLoc(After), MVT::i32, IPM, + DAG.getConstant(SystemZ::IPM_CC, MVT::i32)); +} + +SDValue +SystemZTargetLowering::lowerINTRINSIC_W_CHAIN(SDValue Op, + SelectionDAG &DAG) const { + unsigned Opcode, CCValid; + if (isIntrinsicWithCCAndChain(Op, Opcode, CCValid)) { + assert(Op->getNumValues() == 2 && "Expected only CC result and chain"); + SDValue Glued = emitIntrinsicWithChainAndGlue(DAG, Op, Opcode); + SDValue CC = getCCResult(DAG, Glued.getNode()); + DAG.ReplaceAllUsesOfValueWith(SDValue(Op.getNode(), 0), CC); + return SDValue(); + } + + return SDValue(); +} + SDValue SystemZTargetLowering::LowerOperation(SDValue Op, SelectionDAG &DAG) const { switch (Op.getOpcode()) { @@ -2634,6 +2763,8 @@ SDValue SystemZTargetLowering::LowerOper return lowerSTACKRESTORE(Op, DAG); case ISD::PREFETCH: return lowerPREFETCH(Op, DAG); + case ISD::INTRINSIC_W_CHAIN: + return lowerINTRINSIC_W_CHAIN(Op, DAG); default: llvm_unreachable("Unexpected node to lower"); } @@ -2674,6 +2805,9 @@ const char *SystemZTargetLowering::getTa OPCODE(SEARCH_STRING); OPCODE(IPM); OPCODE(SERIALIZE); + OPCODE(TBEGIN); + OPCODE(TBEGIN_NOFLOAT); + OPCODE(TEND); OPCODE(ATOMIC_SWAPW); OPCODE(ATOMIC_LOADW_ADD); OPCODE(ATOMIC_LOADW_SUB); @@ -3501,6 +3635,50 @@ SystemZTargetLowering::emitStringWrapper return DoneMBB; } +// Update TBEGIN instruction with final opcode and register clobbers. +MachineBasicBlock * +SystemZTargetLowering::emitTransactionBegin(MachineInstr *MI, + MachineBasicBlock *MBB, + unsigned Opcode, + bool NoFloat) const { + MachineFunction &MF = *MBB->getParent(); + const TargetFrameLowering *TFI = Subtarget.getFrameLowering(); + const SystemZInstrInfo *TII = Subtarget.getInstrInfo(); + + // Update opcode. + MI->setDesc(TII->get(Opcode)); + + // We cannot handle a TBEGIN that clobbers the stack or frame pointer. + // Make sure to add the corresponding GRSM bits if they are missing. + uint64_t Control = MI->getOperand(2).getImm(); + static const unsigned GPRControlBit[16] = { + 0x8000, 0x8000, 0x4000, 0x4000, 0x2000, 0x2000, 0x1000, 0x1000, + 0x0800, 0x0800, 0x0400, 0x0400, 0x0200, 0x0200, 0x0100, 0x0100 + }; + Control |= GPRControlBit[15]; + if (TFI->hasFP(MF)) + Control |= GPRControlBit[11]; + MI->getOperand(2).setImm(Control); + + // Add GPR clobbers. + for (int I = 0; I < 16; I++) { + if ((Control & GPRControlBit[I]) == 0) { + unsigned Reg = SystemZMC::GR64Regs[I]; + MI->addOperand(MachineOperand::CreateReg(Reg, true, true)); + } + } + + // Add FPR clobbers. + if (!NoFloat && (Control & 4) != 0) { + for (int I = 0; I < 16; I++) { + unsigned Reg = SystemZMC::FP64Regs[I]; + MI->addOperand(MachineOperand::CreateReg(Reg, true, true)); + } + } + + return MBB; +} + MachineBasicBlock *SystemZTargetLowering:: EmitInstrWithCustomInserter(MachineInstr *MI, MachineBasicBlock *MBB) const { switch (MI->getOpcode()) { @@ -3742,6 +3920,12 @@ EmitInstrWithCustomInserter(MachineInstr return emitStringWrapper(MI, MBB, SystemZ::MVST); case SystemZ::SRSTLoop: return emitStringWrapper(MI, MBB, SystemZ::SRST); + case SystemZ::TBEGIN: + return emitTransactionBegin(MI, MBB, SystemZ::TBEGIN, false); + case SystemZ::TBEGIN_nofloat: + return emitTransactionBegin(MI, MBB, SystemZ::TBEGIN, true); + case SystemZ::TBEGINC: + return emitTransactionBegin(MI, MBB, SystemZ::TBEGINC, true); default: llvm_unreachable("Unexpected instr type to insert"); } Index: llvm-head/test/CodeGen/SystemZ/htm-intrinsics.ll =================================================================== --- /dev/null +++ llvm-head/test/CodeGen/SystemZ/htm-intrinsics.ll @@ -0,0 +1,352 @@ +; Test transactional-execution intrinsics. +; +; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=zEC12 | FileCheck %s + +declare i32 @llvm.s390.tbegin(i8 *, i32) +declare i32 @llvm.s390.tbegin.nofloat(i8 *, i32) +declare void @llvm.s390.tbeginc(i8 *, i32) +declare i32 @llvm.s390.tend() +declare void @llvm.s390.tabort(i64) +declare void @llvm.s390.ntstg(i64, i64 *) +declare i32 @llvm.s390.etnd() +declare void @llvm.s390.ppa.txassist(i32) + +; TBEGIN. +define void @test_tbegin() { +; CHECK-LABEL: test_tbegin: +; CHECK-NOT: stmg +; CHECK: std %f8, +; CHECK: std %f9, +; CHECK: std %f10, +; CHECK: std %f11, +; CHECK: std %f12, +; CHECK: std %f13, +; CHECK: std %f14, +; CHECK: std %f15, +; CHECK: tbegin 0, 65292 +; CHECK: ld %f8, +; CHECK: ld %f9, +; CHECK: ld %f10, +; CHECK: ld %f11, +; CHECK: ld %f12, +; CHECK: ld %f13, +; CHECK: ld %f14, +; CHECK: ld %f15, +; CHECK: br %r14 + call i32 @llvm.s390.tbegin(i8 *null, i32 65292) + ret void +} + +; TBEGIN (nofloat). +define void @test_tbegin_nofloat1() { +; CHECK-LABEL: test_tbegin_nofloat1: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0, 65292 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 65292) + ret void +} + +; TBEGIN (nofloat) with integer CC return value. +define i32 @test_tbegin_nofloat2() { +; CHECK-LABEL: test_tbegin_nofloat2: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0, 65292 +; CHECK: ipm %r2 +; CHECK: srl %r2, 28 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 65292) + ret i32 %res +} + +; TBEGIN (nofloat) with implicit CC check. +define void @test_tbegin_nofloat3(i32 *%ptr) { +; CHECK-LABEL: test_tbegin_nofloat3: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0, 65292 +; CHECK: jnh {{\.L*}} +; CHECK: mvhi 0(%r2), 0 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 65292) + %cmp = icmp eq i32 %res, 2 + br i1 %cmp, label %if.then, label %if.end + +if.then: ; preds = %entry + store i32 0, i32* %ptr, align 4 + br label %if.end + +if.end: ; preds = %if.then, %entry + ret void +} + +; TBEGIN (nofloat) with dual CC use. +define i32 @test_tbegin_nofloat4(i32 %pad, i32 *%ptr) { +; CHECK-LABEL: test_tbegin_nofloat4: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0, 65292 +; CHECK: ipm %r2 +; CHECK: srl %r2, 28 +; CHECK: cijlh %r2, 2, {{\.L*}} +; CHECK: mvhi 0(%r3), 0 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 65292) + %cmp = icmp eq i32 %res, 2 + br i1 %cmp, label %if.then, label %if.end + +if.then: ; preds = %entry + store i32 0, i32* %ptr, align 4 + br label %if.end + +if.end: ; preds = %if.then, %entry + ret i32 %res +} + +; TBEGIN (nofloat) with register. +define void @test_tbegin_nofloat5(i8 *%ptr) { +; CHECK-LABEL: test_tbegin_nofloat5: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0(%r2), 65292 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *%ptr, i32 65292) + ret void +} + +; TBEGIN (nofloat) with GRSM 0x0f00. +define void @test_tbegin_nofloat6() { +; CHECK-LABEL: test_tbegin_nofloat6: +; CHECK: stmg %r6, %r15, +; CHECK-NOT: std +; CHECK: tbegin 0, 3840 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 3840) + ret void +} + +; TBEGIN (nofloat) with GRSM 0xf100. +define void @test_tbegin_nofloat7() { +; CHECK-LABEL: test_tbegin_nofloat7: +; CHECK: stmg %r8, %r15, +; CHECK-NOT: std +; CHECK: tbegin 0, 61696 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 61696) + ret void +} + +; TBEGIN (nofloat) with GRSM 0xfe00 -- stack pointer added automatically. +define void @test_tbegin_nofloat8() { +; CHECK-LABEL: test_tbegin_nofloat8: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0, 65280 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 65024) + ret void +} + +; TBEGIN (nofloat) with GRSM 0xfb00 -- no frame pointer needed. +define void @test_tbegin_nofloat9() { +; CHECK-LABEL: test_tbegin_nofloat9: +; CHECK: stmg %r10, %r15, +; CHECK-NOT: std +; CHECK: tbegin 0, 64256 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 64256) + ret void +} + +; TBEGIN (nofloat) with GRSM 0xfb00 -- frame pointer added automatically. +define void @test_tbegin_nofloat10(i64 %n) { +; CHECK-LABEL: test_tbegin_nofloat10: +; CHECK: stmg %r11, %r15, +; CHECK-NOT: std +; CHECK: tbegin 0, 65280 +; CHECK: br %r14 + %buf = alloca i8, i64 %n + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 64256) + ret void +} + +; TBEGINC. +define void @test_tbeginc() { +; CHECK-LABEL: test_tbeginc: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbeginc 0, 65288 +; CHECK: br %r14 + call void @llvm.s390.tbeginc(i8 *null, i32 65288) + ret void +} + +; TEND with integer CC return value. +define i32 @test_tend1() { +; CHECK-LABEL: test_tend1: +; CHECK: tend +; CHECK: ipm %r2 +; CHECK: srl %r2, 28 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tend() + ret i32 %res +} + +; TEND with implicit CC check. +define void @test_tend3(i32 *%ptr) { +; CHECK-LABEL: test_tend3: +; CHECK: tend +; CHECK: je {{\.L*}} +; CHECK: mvhi 0(%r2), 0 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tend() + %cmp = icmp eq i32 %res, 2 + br i1 %cmp, label %if.then, label %if.end + +if.then: ; preds = %entry + store i32 0, i32* %ptr, align 4 + br label %if.end + +if.end: ; preds = %if.then, %entry + ret void +} + +; TEND with dual CC use. +define i32 @test_tend2(i32 %pad, i32 *%ptr) { +; CHECK-LABEL: test_tend2: +; CHECK: tend +; CHECK: ipm %r2 +; CHECK: srl %r2, 28 +; CHECK: cijlh %r2, 2, {{\.L*}} +; CHECK: mvhi 0(%r3), 0 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tend() + %cmp = icmp eq i32 %res, 2 + br i1 %cmp, label %if.then, label %if.end + +if.then: ; preds = %entry + store i32 0, i32* %ptr, align 4 + br label %if.end + +if.end: ; preds = %if.then, %entry + ret i32 %res +} + +; TABORT with register only. +define void @test_tabort1(i64 %val) { +; CHECK-LABEL: test_tabort1: +; CHECK: tabort 0(%r2) +; CHECK: br %r14 + call void @llvm.s390.tabort(i64 %val) + ret void +} + +; TABORT with immediate only. +define void @test_tabort2(i64 %val) { +; CHECK-LABEL: test_tabort2: +; CHECK: tabort 1234 +; CHECK: br %r14 + call void @llvm.s390.tabort(i64 1234) + ret void +} + +; TABORT with register + immediate. +define void @test_tabort3(i64 %val) { +; CHECK-LABEL: test_tabort3: +; CHECK: tabort 1234(%r2) +; CHECK: br %r14 + %sum = add i64 %val, 1234 + call void @llvm.s390.tabort(i64 %sum) + ret void +} + +; TABORT with out-of-range immediate. +define void @test_tabort4(i64 %val) { +; CHECK-LABEL: test_tabort4: +; CHECK: tabort 0({{%r[1-5]}}) +; CHECK: br %r14 + call void @llvm.s390.tabort(i64 4096) + ret void +} + +; NTSTG with base pointer only. +define void @test_ntstg1(i64 *%ptr, i64 %val) { +; CHECK-LABEL: test_ntstg1: +; CHECK: ntstg %r3, 0(%r2) +; CHECK: br %r14 + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; NTSTG with base and index. +; Check that VSTL doesn't allow an index. +define void @test_ntstg2(i64 *%base, i64 %index, i64 %val) { +; CHECK-LABEL: test_ntstg2: +; CHECK: sllg [[REG:%r[1-5]]], %r3, 3 +; CHECK: ntstg %r4, 0([[REG]],%r2) +; CHECK: br %r14 + %ptr = getelementptr i64, i64 *%base, i64 %index + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; NTSTG with the highest in-range displacement. +define void @test_ntstg3(i64 *%base, i64 %val) { +; CHECK-LABEL: test_ntstg3: +; CHECK: ntstg %r3, 524280(%r2) +; CHECK: br %r14 + %ptr = getelementptr i64, i64 *%base, i64 65535 + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; NTSTG with an out-of-range positive displacement. +define void @test_ntstg4(i64 *%base, i64 %val) { +; CHECK-LABEL: test_ntstg4: +; CHECK: ntstg %r3, 0({{%r[1-5]}}) +; CHECK: br %r14 + %ptr = getelementptr i64, i64 *%base, i64 65536 + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; NTSTG with the lowest in-range displacement. +define void @test_ntstg5(i64 *%base, i64 %val) { +; CHECK-LABEL: test_ntstg5: +; CHECK: ntstg %r3, -524288(%r2) +; CHECK: br %r14 + %ptr = getelementptr i64, i64 *%base, i64 -65536 + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; NTSTG with an out-of-range negative displacement. +define void @test_ntstg6(i64 *%base, i64 %val) { +; CHECK-LABEL: test_ntstg6: +; CHECK: ntstg %r3, 0({{%r[1-5]}}) +; CHECK: br %r14 + %ptr = getelementptr i64, i64 *%base, i64 -65537 + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; ETND. +define i32 @test_etnd() { +; CHECK-LABEL: test_etnd: +; CHECK: etnd %r2 +; CHECK: br %r14 + %res = call i32 @llvm.s390.etnd() + ret i32 %res +} + +; PPA (Transaction-Abort Assist) +define void @test_ppa_txassist(i32 %val) { +; CHECK-LABEL: test_ppa_txassist: +; CHECK: ppa %r2, 0, 1 +; CHECK: br %r14 + call void @llvm.s390.ppa.txassist(i32 %val) + ret void +} + Index: llvm-head/test/MC/SystemZ/insn-bad-zEC12.s =================================================================== --- llvm-head.orig/test/MC/SystemZ/insn-bad-zEC12.s +++ llvm-head/test/MC/SystemZ/insn-bad-zEC12.s @@ -3,6 +3,22 @@ # RUN: FileCheck < %t %s #CHECK: error: invalid operand +#CHECK: ntstg %r0, -524289 +#CHECK: error: invalid operand +#CHECK: ntstg %r0, 524288 + + ntstg %r0, -524289 + ntstg %r0, 524288 + +#CHECK: error: invalid operand +#CHECK: ppa %r0, %r0, -1 +#CHECK: error: invalid operand +#CHECK: ppa %r0, %r0, 16 + + ppa %r0, %r0, -1 + ppa %r0, %r0, 16 + +#CHECK: error: invalid operand #CHECK: risbgn %r0,%r0,0,0,-1 #CHECK: error: invalid operand #CHECK: risbgn %r0,%r0,0,0,64 @@ -22,3 +38,47 @@ risbgn %r0,%r0,-1,0,0 risbgn %r0,%r0,256,0,0 +#CHECK: error: invalid operand +#CHECK: tabort -1 +#CHECK: error: invalid operand +#CHECK: tabort 4096 +#CHECK: error: invalid use of indexed addressing +#CHECK: tabort 0(%r1,%r2) + + tabort -1 + tabort 4096 + tabort 0(%r1,%r2) + +#CHECK: error: invalid operand +#CHECK: tbegin -1, 0 +#CHECK: error: invalid operand +#CHECK: tbegin 4096, 0 +#CHECK: error: invalid use of indexed addressing +#CHECK: tbegin 0(%r1,%r2), 0 +#CHECK: error: invalid operand +#CHECK: tbegin 0, -1 +#CHECK: error: invalid operand +#CHECK: tbegin 0, 65536 + + tbegin -1, 0 + tbegin 4096, 0 + tbegin 0(%r1,%r2), 0 + tbegin 0, -1 + tbegin 0, 65536 + +#CHECK: error: invalid operand +#CHECK: tbeginc -1, 0 +#CHECK: error: invalid operand +#CHECK: tbeginc 4096, 0 +#CHECK: error: invalid use of indexed addressing +#CHECK: tbeginc 0(%r1,%r2), 0 +#CHECK: error: invalid operand +#CHECK: tbeginc 0, -1 +#CHECK: error: invalid operand +#CHECK: tbeginc 0, 65536 + + tbeginc -1, 0 + tbeginc 4096, 0 + tbeginc 0(%r1,%r2), 0 + tbeginc 0, -1 + tbeginc 0, 65536 Index: llvm-head/test/MC/SystemZ/insn-good-zEC12.s =================================================================== --- llvm-head.orig/test/MC/SystemZ/insn-good-zEC12.s +++ llvm-head/test/MC/SystemZ/insn-good-zEC12.s @@ -1,6 +1,48 @@ # For zEC12 and above. # RUN: llvm-mc -triple s390x-linux-gnu -mcpu=zEC12 -show-encoding %s | FileCheck %s +#CHECK: etnd %r0 # encoding: [0xb2,0xec,0x00,0x00] +#CHECK: etnd %r15 # encoding: [0xb2,0xec,0x00,0xf0] +#CHECK: etnd %r7 # encoding: [0xb2,0xec,0x00,0x70] + + etnd %r0 + etnd %r15 + etnd %r7 + +#CHECK: ntstg %r0, -524288 # encoding: [0xe3,0x00,0x00,0x00,0x80,0x25] +#CHECK: ntstg %r0, -1 # encoding: [0xe3,0x00,0x0f,0xff,0xff,0x25] +#CHECK: ntstg %r0, 0 # encoding: [0xe3,0x00,0x00,0x00,0x00,0x25] +#CHECK: ntstg %r0, 1 # encoding: [0xe3,0x00,0x00,0x01,0x00,0x25] +#CHECK: ntstg %r0, 524287 # encoding: [0xe3,0x00,0x0f,0xff,0x7f,0x25] +#CHECK: ntstg %r0, 0(%r1) # encoding: [0xe3,0x00,0x10,0x00,0x00,0x25] +#CHECK: ntstg %r0, 0(%r15) # encoding: [0xe3,0x00,0xf0,0x00,0x00,0x25] +#CHECK: ntstg %r0, 524287(%r1,%r15) # encoding: [0xe3,0x01,0xff,0xff,0x7f,0x25] +#CHECK: ntstg %r0, 524287(%r15,%r1) # encoding: [0xe3,0x0f,0x1f,0xff,0x7f,0x25] +#CHECK: ntstg %r15, 0 # encoding: [0xe3,0xf0,0x00,0x00,0x00,0x25] + + ntstg %r0, -524288 + ntstg %r0, -1 + ntstg %r0, 0 + ntstg %r0, 1 + ntstg %r0, 524287 + ntstg %r0, 0(%r1) + ntstg %r0, 0(%r15) + ntstg %r0, 524287(%r1,%r15) + ntstg %r0, 524287(%r15,%r1) + ntstg %r15, 0 + +#CHECK: ppa %r0, %r0, 0 # encoding: [0xb2,0xe8,0x00,0x00] +#CHECK: ppa %r0, %r0, 15 # encoding: [0xb2,0xe8,0xf0,0x00] +#CHECK: ppa %r0, %r15, 0 # encoding: [0xb2,0xe8,0x00,0x0f] +#CHECK: ppa %r4, %r6, 7 # encoding: [0xb2,0xe8,0x70,0x46] +#CHECK: ppa %r15, %r0, 0 # encoding: [0xb2,0xe8,0x00,0xf0] + + ppa %r0, %r0, 0 + ppa %r0, %r0, 15 + ppa %r0, %r15, 0 + ppa %r4, %r6, 7 + ppa %r15, %r0, 0 + #CHECK: risbgn %r0, %r0, 0, 0, 0 # encoding: [0xec,0x00,0x00,0x00,0x00,0x59] #CHECK: risbgn %r0, %r0, 0, 0, 63 # encoding: [0xec,0x00,0x00,0x00,0x3f,0x59] #CHECK: risbgn %r0, %r0, 0, 255, 0 # encoding: [0xec,0x00,0x00,0xff,0x00,0x59] @@ -17,3 +59,68 @@ risbgn %r15,%r0,0,0,0 risbgn %r4,%r5,6,7,8 +#CHECK: tabort 0 # encoding: [0xb2,0xfc,0x00,0x00] +#CHECK: tabort 0(%r1) # encoding: [0xb2,0xfc,0x10,0x00] +#CHECK: tabort 0(%r15) # encoding: [0xb2,0xfc,0xf0,0x00] +#CHECK: tabort 4095 # encoding: [0xb2,0xfc,0x0f,0xff] +#CHECK: tabort 4095(%r1) # encoding: [0xb2,0xfc,0x1f,0xff] +#CHECK: tabort 4095(%r15) # encoding: [0xb2,0xfc,0xff,0xff] + + tabort 0 + tabort 0(%r1) + tabort 0(%r15) + tabort 4095 + tabort 4095(%r1) + tabort 4095(%r15) + +#CHECK: tbegin 0, 0 # encoding: [0xe5,0x60,0x00,0x00,0x00,0x00] +#CHECK: tbegin 4095, 0 # encoding: [0xe5,0x60,0x0f,0xff,0x00,0x00] +#CHECK: tbegin 0, 0 # encoding: [0xe5,0x60,0x00,0x00,0x00,0x00] +#CHECK: tbegin 0, 1 # encoding: [0xe5,0x60,0x00,0x00,0x00,0x01] +#CHECK: tbegin 0, 32767 # encoding: [0xe5,0x60,0x00,0x00,0x7f,0xff] +#CHECK: tbegin 0, 32768 # encoding: [0xe5,0x60,0x00,0x00,0x80,0x00] +#CHECK: tbegin 0, 65535 # encoding: [0xe5,0x60,0x00,0x00,0xff,0xff] +#CHECK: tbegin 0(%r1), 42 # encoding: [0xe5,0x60,0x10,0x00,0x00,0x2a] +#CHECK: tbegin 0(%r15), 42 # encoding: [0xe5,0x60,0xf0,0x00,0x00,0x2a] +#CHECK: tbegin 4095(%r1), 42 # encoding: [0xe5,0x60,0x1f,0xff,0x00,0x2a] +#CHECK: tbegin 4095(%r15), 42 # encoding: [0xe5,0x60,0xff,0xff,0x00,0x2a] + + tbegin 0, 0 + tbegin 4095, 0 + tbegin 0, 0 + tbegin 0, 1 + tbegin 0, 32767 + tbegin 0, 32768 + tbegin 0, 65535 + tbegin 0(%r1), 42 + tbegin 0(%r15), 42 + tbegin 4095(%r1), 42 + tbegin 4095(%r15), 42 + +#CHECK: tbeginc 0, 0 # encoding: [0xe5,0x61,0x00,0x00,0x00,0x00] +#CHECK: tbeginc 4095, 0 # encoding: [0xe5,0x61,0x0f,0xff,0x00,0x00] +#CHECK: tbeginc 0, 0 # encoding: [0xe5,0x61,0x00,0x00,0x00,0x00] +#CHECK: tbeginc 0, 1 # encoding: [0xe5,0x61,0x00,0x00,0x00,0x01] +#CHECK: tbeginc 0, 32767 # encoding: [0xe5,0x61,0x00,0x00,0x7f,0xff] +#CHECK: tbeginc 0, 32768 # encoding: [0xe5,0x61,0x00,0x00,0x80,0x00] +#CHECK: tbeginc 0, 65535 # encoding: [0xe5,0x61,0x00,0x00,0xff,0xff] +#CHECK: tbeginc 0(%r1), 42 # encoding: [0xe5,0x61,0x10,0x00,0x00,0x2a] +#CHECK: tbeginc 0(%r15), 42 # encoding: [0xe5,0x61,0xf0,0x00,0x00,0x2a] +#CHECK: tbeginc 4095(%r1), 42 # encoding: [0xe5,0x61,0x1f,0xff,0x00,0x2a] +#CHECK: tbeginc 4095(%r15), 42 # encoding: [0xe5,0x61,0xff,0xff,0x00,0x2a] + + tbeginc 0, 0 + tbeginc 4095, 0 + tbeginc 0, 0 + tbeginc 0, 1 + tbeginc 0, 32767 + tbeginc 0, 32768 + tbeginc 0, 65535 + tbeginc 0(%r1), 42 + tbeginc 0(%r15), 42 + tbeginc 4095(%r1), 42 + tbeginc 4095(%r15), 42 + +#CHECK: tend # encoding: [0xb2,0xf8,0x00,0x00] + + tend Index: llvm-head/test/MC/SystemZ/insn-bad-z196.s =================================================================== --- llvm-head.orig/test/MC/SystemZ/insn-bad-z196.s +++ llvm-head/test/MC/SystemZ/insn-bad-z196.s @@ -244,6 +244,11 @@ cxlgbr %f0, 16, %r0, 0 cxlgbr %f2, 0, %r0, 0 +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: etnd %r7 + + etnd %r7 + #CHECK: error: invalid operand #CHECK: fidbra %f0, 0, %f0, -1 #CHECK: error: invalid operand @@ -546,6 +551,16 @@ locr %r0,%r0,-1 locr %r0,%r0,16 +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: ntstg %r0, 524287(%r1,%r15) + + ntstg %r0, 524287(%r1,%r15) + +#CHECK: error: {{(instruction requires: processor-assist)?}} +#CHECK: ppa %r4, %r6, 7 + + ppa %r4, %r6, 7 + #CHECK: error: {{(instruction requires: miscellaneous-extensions)?}} #CHECK: risbgn %r1, %r2, 0, 0, 0 @@ -690,3 +705,24 @@ stocg %r0,-524289,1 stocg %r0,524288,1 stocg %r0,0(%r1,%r2),1 + +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: tabort 4095(%r1) + + tabort 4095(%r1) + +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: tbegin 4095(%r1), 42 + + tbegin 4095(%r1), 42 + +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: tbeginc 4095(%r1), 42 + + tbeginc 4095(%r1), 42 + +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: tend + + tend + Index: llvm-head/test/MC/Disassembler/SystemZ/insns.txt =================================================================== --- llvm-head.orig/test/MC/Disassembler/SystemZ/insns.txt +++ llvm-head/test/MC/Disassembler/SystemZ/insns.txt @@ -2503,6 +2503,15 @@ # CHECK: ear %r15, %a15 0xb2 0x4f 0x00 0xff +# CHECK: etnd %r0 +0xb2 0xec 0x00 0x00 + +# CHECK: etnd %r15 +0xb2 0xec 0x00 0xf0 + +# CHECK: etnd %r7 +0xb2 0xec 0x00 0x70 + # CHECK: fidbr %f0, 0, %f0 0xb3 0x5f 0x00 0x00 @@ -6034,6 +6043,36 @@ # CHECK: ny %r15, 0 0xe3 0xf0 0x00 0x00 0x00 0x54 +# CHECK: ntstg %r0, -524288 +0xe3 0x00 0x00 0x00 0x80 0x25 + +# CHECK: ntstg %r0, -1 +0xe3 0x00 0x0f 0xff 0xff 0x25 + +# CHECK: ntstg %r0, 0 +0xe3 0x00 0x00 0x00 0x00 0x25 + +# CHECK: ntstg %r0, 1 +0xe3 0x00 0x00 0x01 0x00 0x25 + +# CHECK: ntstg %r0, 524287 +0xe3 0x00 0x0f 0xff 0x7f 0x25 + +# CHECK: ntstg %r0, 0(%r1) +0xe3 0x00 0x10 0x00 0x00 0x25 + +# CHECK: ntstg %r0, 0(%r15) +0xe3 0x00 0xf0 0x00 0x00 0x25 + +# CHECK: ntstg %r0, 524287(%r1,%r15) +0xe3 0x01 0xff 0xff 0x7f 0x25 + +# CHECK: ntstg %r0, 524287(%r15,%r1) +0xe3 0x0f 0x1f 0xff 0x7f 0x25 + +# CHECK: ntstg %r15, 0 +0xe3 0xf0 0x00 0x00 0x00 0x25 + # CHECK: oc 0(1), 0 0xd6 0x00 0x00 0x00 0x00 0x00 @@ -6346,6 +6385,21 @@ # CHECK: popcnt %r7, %r8 0xb9 0xe1 0x00 0x78 +# CHECK: ppa %r0, %r0, 0 +0xb2 0xe8 0x00 0x00 + +# CHECK: ppa %r0, %r0, 15 +0xb2 0xe8 0xf0 0x00 + +# CHECK: ppa %r0, %r15, 0 +0xb2 0xe8 0x00 0x0f + +# CHECK: ppa %r4, %r6, 7 +0xb2 0xe8 0x70 0x46 + +# CHECK: ppa %r15, %r0, 0 +0xb2 0xe8 0x00 0xf0 + # CHECK: risbg %r0, %r0, 0, 0, 0 0xec 0x00 0x00 0x00 0x00 0x55 @@ -8062,6 +8116,93 @@ # CHECK: sy %r15, 0 0xe3 0xf0 0x00 0x00 0x00 0x5b +# CHECK: tabort 0 +0xb2 0xfc 0x00 0x00 + +# CHECK: tabort 0(%r1) +0xb2 0xfc 0x10 0x00 + +# CHECK: tabort 0(%r15) +0xb2 0xfc 0xf0 0x00 + +# CHECK: tabort 4095 +0xb2 0xfc 0x0f 0xff + +# CHECK: tabort 4095(%r1) +0xb2 0xfc 0x1f 0xff + +# CHECK: tabort 4095(%r15) +0xb2 0xfc 0xff 0xff + +# CHECK: tbegin 0, 0 +0xe5 0x60 0x00 0x00 0x00 0x00 + +# CHECK: tbegin 4095, 0 +0xe5 0x60 0x0f 0xff 0x00 0x00 + +# CHECK: tbegin 0, 0 +0xe5 0x60 0x00 0x00 0x00 0x00 + +# CHECK: tbegin 0, 1 +0xe5 0x60 0x00 0x00 0x00 0x01 + +# CHECK: tbegin 0, 32767 +0xe5 0x60 0x00 0x00 0x7f 0xff + +# CHECK: tbegin 0, 32768 +0xe5 0x60 0x00 0x00 0x80 0x00 + +# CHECK: tbegin 0, 65535 +0xe5 0x60 0x00 0x00 0xff 0xff + +# CHECK: tbegin 0(%r1), 42 +0xe5 0x60 0x10 0x00 0x00 0x2a + +# CHECK: tbegin 0(%r15), 42 +0xe5 0x60 0xf0 0x00 0x00 0x2a + +# CHECK: tbegin 4095(%r1), 42 +0xe5 0x60 0x1f 0xff 0x00 0x2a + +# CHECK: tbegin 4095(%r15), 42 +0xe5 0x60 0xff 0xff 0x00 0x2a + +# CHECK: tbeginc 0, 0 +0xe5 0x61 0x00 0x00 0x00 0x00 + +# CHECK: tbeginc 4095, 0 +0xe5 0x61 0x0f 0xff 0x00 0x00 + +# CHECK: tbeginc 0, 0 +0xe5 0x61 0x00 0x00 0x00 0x00 + +# CHECK: tbeginc 0, 1 +0xe5 0x61 0x00 0x00 0x00 0x01 + +# CHECK: tbeginc 0, 32767 +0xe5 0x61 0x00 0x00 0x7f 0xff + +# CHECK: tbeginc 0, 32768 +0xe5 0x61 0x00 0x00 0x80 0x00 + +# CHECK: tbeginc 0, 65535 +0xe5 0x61 0x00 0x00 0xff 0xff + +# CHECK: tbeginc 0(%r1), 42 +0xe5 0x61 0x10 0x00 0x00 0x2a + +# CHECK: tbeginc 0(%r15), 42 +0xe5 0x61 0xf0 0x00 0x00 0x2a + +# CHECK: tbeginc 4095(%r1), 42 +0xe5 0x61 0x1f 0xff 0x00 0x2a + +# CHECK: tbeginc 4095(%r15), 42 +0xe5 0x61 0xff 0xff 0x00 0x2a + +# CHECK: tend +0xb2 0xf8 0x00 0x00 + # CHECK: tm 0, 0 0x91 0x00 0x00 0x00 llvm-svn: 233803
2015-04-01 20:51:43 +08:00
class InstS<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<4, outs, ins, asmstr, pattern> {
field bits<32> Inst;
field bits<32> SoftFail = 0;
bits<16> BD2;
let Inst{31-16} = op;
let Inst{15-0} = BD2;
}
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
class InstVRIa<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<16> I2;
bits<4> M3;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = 0;
let Inst{31-16} = I2;
let Inst{15-12} = M3;
let Inst{11} = V1{4};
let Inst{10-8} = 0;
let Inst{7-0} = op{7-0};
}
class InstVRIb<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<8> I2;
bits<8> I3;
bits<4> M4;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = 0;
let Inst{31-24} = I2;
let Inst{23-16} = I3;
let Inst{15-12} = M4;
let Inst{11} = V1{4};
let Inst{10-8} = 0;
let Inst{7-0} = op{7-0};
}
class InstVRIc<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<5> V3;
bits<16> I2;
bits<4> M4;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = V3{3-0};
let Inst{31-16} = I2;
let Inst{15-12} = M4;
let Inst{11} = V1{4};
let Inst{10} = V3{4};
let Inst{9-8} = 0;
let Inst{7-0} = op{7-0};
}
class InstVRId<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<5> V2;
bits<5> V3;
bits<8> I4;
bits<4> M5;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = V2{3-0};
let Inst{31-28} = V3{3-0};
let Inst{27-24} = 0;
let Inst{23-16} = I4;
let Inst{15-12} = M5;
let Inst{11} = V1{4};
let Inst{10} = V2{4};
let Inst{9} = V3{4};
let Inst{8} = 0;
let Inst{7-0} = op{7-0};
}
class InstVRIe<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<5> V2;
bits<12> I3;
bits<4> M4;
bits<4> M5;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = V2{3-0};
let Inst{31-20} = I3;
let Inst{19-16} = M5;
let Inst{15-12} = M4;
let Inst{11} = V1{4};
let Inst{10} = V2{4};
let Inst{9-8} = 0;
let Inst{7-0} = op{7-0};
}
// Depending on the instruction mnemonic, certain bits may be or-ed into
// the M4 value provided as explicit operand. These are passed as m4or.
class InstVRRa<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern,
bits<4> m4or = 0>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<5> V2;
bits<4> M3;
bits<4> M4;
bits<4> M5;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = V2{3-0};
let Inst{31-24} = 0;
let Inst{23-20} = M5;
let Inst{19} = !if (!eq (m4or{3}, 1), 1, M4{3});
let Inst{18} = !if (!eq (m4or{2}, 1), 1, M4{2});
let Inst{17} = !if (!eq (m4or{1}, 1), 1, M4{1});
let Inst{16} = !if (!eq (m4or{0}, 1), 1, M4{0});
let Inst{15-12} = M3;
let Inst{11} = V1{4};
let Inst{10} = V2{4};
let Inst{9-8} = 0;
let Inst{7-0} = op{7-0};
}
// Depending on the instruction mnemonic, certain bits may be or-ed into
// the M5 value provided as explicit operand. These are passed as m5or.
class InstVRRb<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern,
bits<4> m5or = 0>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<5> V2;
bits<5> V3;
bits<4> M4;
bits<4> M5;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = V2{3-0};
let Inst{31-28} = V3{3-0};
let Inst{27-24} = 0;
let Inst{23} = !if (!eq (m5or{3}, 1), 1, M5{3});
let Inst{22} = !if (!eq (m5or{2}, 1), 1, M5{2});
let Inst{21} = !if (!eq (m5or{1}, 1), 1, M5{1});
let Inst{20} = !if (!eq (m5or{0}, 1), 1, M5{0});
let Inst{19-16} = 0;
let Inst{15-12} = M4;
let Inst{11} = V1{4};
let Inst{10} = V2{4};
let Inst{9} = V3{4};
let Inst{8} = 0;
let Inst{7-0} = op{7-0};
}
class InstVRRc<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<5> V2;
bits<5> V3;
bits<4> M4;
bits<4> M5;
bits<4> M6;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = V2{3-0};
let Inst{31-28} = V3{3-0};
let Inst{27-24} = 0;
let Inst{23-20} = M6;
let Inst{19-16} = M5;
let Inst{15-12} = M4;
let Inst{11} = V1{4};
let Inst{10} = V2{4};
let Inst{9} = V3{4};
let Inst{8} = 0;
let Inst{7-0} = op{7-0};
}
// Depending on the instruction mnemonic, certain bits may be or-ed into
// the M6 value provided as explicit operand. These are passed as m6or.
class InstVRRd<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern,
bits<4> m6or = 0>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<5> V2;
bits<5> V3;
bits<5> V4;
bits<4> M5;
bits<4> M6;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = V2{3-0};
let Inst{31-28} = V3{3-0};
let Inst{27-24} = M5;
let Inst{23} = !if (!eq (m6or{3}, 1), 1, M6{3});
let Inst{22} = !if (!eq (m6or{2}, 1), 1, M6{2});
let Inst{21} = !if (!eq (m6or{1}, 1), 1, M6{1});
let Inst{20} = !if (!eq (m6or{0}, 1), 1, M6{0});
let Inst{19-16} = 0;
let Inst{15-12} = V4{3-0};
let Inst{11} = V1{4};
let Inst{10} = V2{4};
let Inst{9} = V3{4};
let Inst{8} = V4{4};
let Inst{7-0} = op{7-0};
}
class InstVRRe<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<5> V2;
bits<5> V3;
bits<5> V4;
bits<4> M5;
bits<4> M6;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = V2{3-0};
let Inst{31-28} = V3{3-0};
let Inst{27-24} = M6;
let Inst{23-20} = 0;
let Inst{19-16} = M5;
let Inst{15-12} = V4{3-0};
let Inst{11} = V1{4};
let Inst{10} = V2{4};
let Inst{9} = V3{4};
let Inst{8} = V4{4};
let Inst{7-0} = op{7-0};
}
class InstVRRf<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<4> R2;
bits<4> R3;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = R2;
let Inst{31-28} = R3;
let Inst{27-12} = 0;
let Inst{11} = V1{4};
let Inst{10-8} = 0;
let Inst{7-0} = op{7-0};
}
class InstVRSa<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<16> BD2;
bits<5> V3;
bits<4> M4;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = V3{3-0};
let Inst{31-16} = BD2;
let Inst{15-12} = M4;
let Inst{11} = V1{4};
let Inst{10} = V3{4};
let Inst{9-8} = 0;
let Inst{7-0} = op{7-0};
}
class InstVRSb<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<16> BD2;
bits<4> R3;
bits<4> M4;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-32} = R3;
let Inst{31-16} = BD2;
let Inst{15-12} = M4;
let Inst{11} = V1{4};
let Inst{10-8} = 0;
let Inst{7-0} = op{7-0};
}
class InstVRSc<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<4> R1;
bits<16> BD2;
bits<5> V3;
bits<4> M4;
let Inst{47-40} = op{15-8};
let Inst{39-36} = R1;
let Inst{35-32} = V3{3-0};
let Inst{31-16} = BD2;
let Inst{15-12} = M4;
let Inst{11} = 0;
let Inst{10} = V3{4};
let Inst{9-8} = 0;
let Inst{7-0} = op{7-0};
}
class InstVRV<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<21> VBD2;
bits<4> M3;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-16} = VBD2{19-0};
let Inst{15-12} = M3;
let Inst{11} = V1{4};
let Inst{10} = VBD2{20};
let Inst{9-8} = 0;
let Inst{7-0} = op{7-0};
}
class InstVRX<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSystemZ<6, outs, ins, asmstr, pattern> {
field bits<48> Inst;
field bits<48> SoftFail = 0;
bits<5> V1;
bits<20> XBD2;
bits<4> M3;
let Inst{47-40} = op{15-8};
let Inst{39-36} = V1{3-0};
let Inst{35-16} = XBD2;
let Inst{15-12} = M3;
let Inst{11} = V1{4};
let Inst{10-8} = 0;
let Inst{7-0} = op{7-0};
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//===----------------------------------------------------------------------===//
// Instruction definitions with semantics
//===----------------------------------------------------------------------===//
//
[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 16:57:02 +08:00
// These classes have the form [Cond]<Category><Format>, where <Format> is one
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
// of the formats defined above and where <Category> describes the inputs
[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 16:57:02 +08:00
// and outputs. "Cond" is used if the instruction is conditional,
// in which case the 4-bit condition-code mask is added as a final operand.
// <Category> can be one of:
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//
// Inherent:
// One register output operand and no input operands.
//
[SystemZ] Add definitions for BRCT and BRCTG llvm-svn: 187721
2013-08-05 19:07:38 +08:00
// BranchUnary:
// One register output operand, one register input operand and
// one branch displacement. The instructions stores a modified
// form of the source register in the destination register and
// branches on the result.
//
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
// LoadMultiple:
// One address input operand and two explicit output operands.
// The instruction loads a range of registers from the address,
// with the explicit operands giving the first and last register
// to load. Other loaded registers are added as implicit definitions.
//
// StoreMultiple:
// Two explicit input register operands and an address operand.
// The instruction stores a range of registers to the address,
// with the explicit operands giving the first and last register
// to store. Other stored registers are added as implicit uses.
//
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
// StoreLength:
// One value operand, one length operand and one address operand.
// The instruction stores the value operand to the address but
// doesn't write more than the number of bytes specified by the
// length operand.
//
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
// Unary:
[SystemZ] Tweak instruction format classifications There's no real need to have Shift as a separate format type from Binary. The comments for other format types were too specific and in some cases no longer accurate. Just a clean-up, no behavioral change intended. llvm-svn: 212707
2014-07-10 19:29:23 +08:00
// One register output operand and one input operand.
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
// Store:
// One address operand and one other input operand. The instruction
// stores to the address.
//
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
// Binary:
[SystemZ] Tweak instruction format classifications There's no real need to have Shift as a separate format type from Binary. The comments for other format types were too specific and in some cases no longer accurate. Just a clean-up, no behavioral change intended. llvm-svn: 212707
2014-07-10 19:29:23 +08:00
// One register output operand and two input operands.
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
// StoreBinary:
// One address operand and two other input operands. The instruction
// stores to the address.
//
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
// Compare:
[SystemZ] Tweak instruction format classifications There's no real need to have Shift as a separate format type from Binary. The comments for other format types were too specific and in some cases no longer accurate. Just a clean-up, no behavioral change intended. llvm-svn: 212707
2014-07-10 19:29:23 +08:00
// Two input operands and an implicit CC output operand.
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//
// Ternary:
[SystemZ] Tweak instruction format classifications There's no real need to have Shift as a separate format type from Binary. The comments for other format types were too specific and in some cases no longer accurate. Just a clean-up, no behavioral change intended. llvm-svn: 212707
2014-07-10 19:29:23 +08:00
// One register output operand and three input operands.
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
// Quaternary:
// One register output operand and four input operands.
//
[SystemZ] Add MC support for interlocked-access 1 instructions llvm-svn: 197984
2013-12-24 23:14:05 +08:00
// LoadAndOp:
[SystemZ] Tweak instruction format classifications There's no real need to have Shift as a separate format type from Binary. The comments for other format types were too specific and in some cases no longer accurate. Just a clean-up, no behavioral change intended. llvm-svn: 212707
2014-07-10 19:29:23 +08:00
// One output operand and two input operands, one of which is an address.
// The instruction both reads from and writes to the address.
[SystemZ] Add MC support for interlocked-access 1 instructions llvm-svn: 197984
2013-12-24 23:14:05 +08:00
//
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
// CmpSwap:
[SystemZ] Tweak instruction format classifications There's no real need to have Shift as a separate format type from Binary. The comments for other format types were too specific and in some cases no longer accurate. Just a clean-up, no behavioral change intended. llvm-svn: 212707
2014-07-10 19:29:23 +08:00
// One output operand and three input operands, one of which is an address.
// The instruction both reads from and writes to the address.
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//
// RotateSelect:
// One output operand and five input operands. The first two operands
// are registers and the other three are immediates.
//
[SystemZ] Add basic prefetch support Just the instructions and intrinsics for now. llvm-svn: 189100
2013-08-23 19:36:42 +08:00
// Prefetch:
// One 4-bit immediate operand and one address operand. The immediate
// operand is 1 for a load prefetch and 2 for a store prefetch.
//
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
// The format determines which input operands are tied to output operands,
// and also determines the shape of any address operand.
//
// Multiclasses of the form <Category><Format>Pair define two instructions,
// one with <Category><Format> and one with <Category><Format>Y. The name
// of the first instruction has no suffix, the name of the second has
// an extra "y".
//
//===----------------------------------------------------------------------===//
class InherentRRE<string mnemonic, bits<16> opcode, RegisterOperand cls,
dag src>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRRE<opcode, (outs cls:$R1), (ins),
[SystemZ] Add a definition of the IPM instruction llvm-svn: 188161
2013-08-12 18:05:58 +08:00
mnemonic#"\t$R1",
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
[(set cls:$R1, src)]> {
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let R2 = 0;
}
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
class InherentVRIa<string mnemonic, bits<16> opcode, bits<16> value>
: InstVRIa<opcode, (outs VR128:$V1), (ins), mnemonic#"\t$V1", []> {
let I2 = value;
let M3 = 0;
}
[SystemZ] Add definitions for BRCT and BRCTG llvm-svn: 187721
2013-08-05 19:07:38 +08:00
class BranchUnaryRI<string mnemonic, bits<12> opcode, RegisterOperand cls>
: InstRI<opcode, (outs cls:$R1), (ins cls:$R1src, brtarget16:$I2),
mnemonic##"\t$R1, $I2", []> {
let isBranch = 1;
let isTerminator = 1;
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class LoadMultipleRSY<string mnemonic, bits<16> opcode, RegisterOperand cls>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRSY<opcode, (outs cls:$R1, cls:$R3), (ins bdaddr20only:$BD2),
mnemonic#"\t$R1, $R3, $BD2", []> {
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
}
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
class LoadMultipleVRSa<string mnemonic, bits<16> opcode>
: InstVRSa<opcode, (outs VR128:$V1, VR128:$V3), (ins bdaddr12only:$BD2),
mnemonic#"\t$V1, $V3, $BD2", []> {
let M4 = 0;
let mayLoad = 1;
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class StoreRILPC<string mnemonic, bits<12> opcode, SDPatternOperator operator,
RegisterOperand cls>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRIL<opcode, (outs), (ins cls:$R1, pcrel32:$I2),
mnemonic#"\t$R1, $I2",
[(operator cls:$R1, pcrel32:$I2)]> {
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayStore = 1;
// We want PC-relative addresses to be tried ahead of BD and BDX addresses.
// However, BDXs have two extra operands and are therefore 6 units more
// complex.
let AddedComplexity = 7;
}
class StoreRX<string mnemonic, bits<8> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, bits<5> bytes,
AddressingMode mode = bdxaddr12only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRX<opcode, (outs), (ins cls:$R1, mode:$XBD2),
mnemonic#"\t$R1, $XBD2",
[(operator cls:$R1, mode:$XBD2)]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayStore = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
class StoreRXY<string mnemonic, bits<16> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, bits<5> bytes,
AddressingMode mode = bdxaddr20only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRXY<opcode, (outs), (ins cls:$R1, mode:$XBD2),
mnemonic#"\t$R1, $XBD2",
[(operator cls:$R1, mode:$XBD2)]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayStore = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
multiclass StoreRXPair<string mnemonic, bits<8> rxOpcode, bits<16> rxyOpcode,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
SDPatternOperator operator, RegisterOperand cls,
bits<5> bytes> {
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispKey = mnemonic ## #cls in {
let DispSize = "12" in
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
def "" : StoreRX<mnemonic, rxOpcode, operator, cls, bytes, bdxaddr12pair>;
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispSize = "20" in
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
def Y : StoreRXY<mnemonic#"y", rxyOpcode, operator, cls, bytes,
bdxaddr20pair>;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
}
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
class StoreVRX<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr, bits<5> bytes, bits<4> type = 0>
: InstVRX<opcode, (outs), (ins tr.op:$V1, bdxaddr12only:$XBD2),
mnemonic#"\t$V1, $XBD2",
[(set tr.op:$V1, (tr.vt (operator bdxaddr12only:$XBD2)))]> {
let M3 = type;
let mayStore = 1;
let AccessBytes = bytes;
}
class StoreLengthVRSb<string mnemonic, bits<16> opcode,
SDPatternOperator operator, bits<5> bytes>
: InstVRSb<opcode, (outs), (ins VR128:$V1, GR32:$R3, bdaddr12only:$BD2),
mnemonic#"\t$V1, $R3, $BD2",
[(operator VR128:$V1, GR32:$R3, bdaddr12only:$BD2)]> {
let M4 = 0;
let mayStore = 1;
let AccessBytes = bytes;
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class StoreMultipleRSY<string mnemonic, bits<16> opcode, RegisterOperand cls>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRSY<opcode, (outs), (ins cls:$R1, cls:$R3, bdaddr20only:$BD2),
mnemonic#"\t$R1, $R3, $BD2", []> {
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayStore = 1;
}
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
class StoreMultipleVRSa<string mnemonic, bits<16> opcode>
: InstVRSa<opcode, (outs), (ins VR128:$V1, VR128:$V3, bdaddr12only:$BD2),
mnemonic#"\t$V1, $V3, $BD2", []> {
let M4 = 0;
let mayStore = 1;
}
[SystemZ] Prefer LHI;ST... over LAY;MV... If we had a store of an integer to memory, and the integer and store size were suitable for a form of MV..., we used MV... no matter what. We could then have sequences like: lay %r2, 0(%r3,%r4) mvi 0(%r2), 4 In these cases it seems better to force the constant into a register and use a normal store: lhi %r2, 4 stc %r2, 0(%r3, %r4) since %r2 is more likely to be hoisted and is easier to rematerialize. llvm-svn: 189098
2013-08-23 19:18:53 +08:00
// StoreSI* instructions are used to store an integer to memory, but the
// addresses are more restricted than for normal stores. If we are in the
// situation of having to force either the address into a register or the
// constant into a register, it's usually better to do the latter.
// We therefore match the address in the same way as a normal store and
// only use the StoreSI* instruction if the matched address is suitable.
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class StoreSI<string mnemonic, bits<8> opcode, SDPatternOperator operator,
[SystemZ] Prefer LHI;ST... over LAY;MV... If we had a store of an integer to memory, and the integer and store size were suitable for a form of MV..., we used MV... no matter what. We could then have sequences like: lay %r2, 0(%r3,%r4) mvi 0(%r2), 4 In these cases it seems better to force the constant into a register and use a normal store: lhi %r2, 4 stc %r2, 0(%r3, %r4) since %r2 is more likely to be hoisted and is easier to rematerialize. llvm-svn: 189098
2013-08-23 19:18:53 +08:00
Immediate imm>
: InstSI<opcode, (outs), (ins mviaddr12pair:$BD1, imm:$I2),
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
mnemonic#"\t$BD1, $I2",
[SystemZ] Prefer LHI;ST... over LAY;MV... If we had a store of an integer to memory, and the integer and store size were suitable for a form of MV..., we used MV... no matter what. We could then have sequences like: lay %r2, 0(%r3,%r4) mvi 0(%r2), 4 In these cases it seems better to force the constant into a register and use a normal store: lhi %r2, 4 stc %r2, 0(%r3, %r4) since %r2 is more likely to be hoisted and is easier to rematerialize. llvm-svn: 189098
2013-08-23 19:18:53 +08:00
[(operator imm:$I2, mviaddr12pair:$BD1)]> {
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayStore = 1;
}
class StoreSIY<string mnemonic, bits<16> opcode, SDPatternOperator operator,
[SystemZ] Prefer LHI;ST... over LAY;MV... If we had a store of an integer to memory, and the integer and store size were suitable for a form of MV..., we used MV... no matter what. We could then have sequences like: lay %r2, 0(%r3,%r4) mvi 0(%r2), 4 In these cases it seems better to force the constant into a register and use a normal store: lhi %r2, 4 stc %r2, 0(%r3, %r4) since %r2 is more likely to be hoisted and is easier to rematerialize. llvm-svn: 189098
2013-08-23 19:18:53 +08:00
Immediate imm>
: InstSIY<opcode, (outs), (ins mviaddr20pair:$BD1, imm:$I2),
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
mnemonic#"\t$BD1, $I2",
[SystemZ] Prefer LHI;ST... over LAY;MV... If we had a store of an integer to memory, and the integer and store size were suitable for a form of MV..., we used MV... no matter what. We could then have sequences like: lay %r2, 0(%r3,%r4) mvi 0(%r2), 4 In these cases it seems better to force the constant into a register and use a normal store: lhi %r2, 4 stc %r2, 0(%r3, %r4) since %r2 is more likely to be hoisted and is easier to rematerialize. llvm-svn: 189098
2013-08-23 19:18:53 +08:00
[(operator imm:$I2, mviaddr20pair:$BD1)]> {
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayStore = 1;
}
class StoreSIL<string mnemonic, bits<16> opcode, SDPatternOperator operator,
Immediate imm>
[SystemZ] Prefer LHI;ST... over LAY;MV... If we had a store of an integer to memory, and the integer and store size were suitable for a form of MV..., we used MV... no matter what. We could then have sequences like: lay %r2, 0(%r3,%r4) mvi 0(%r2), 4 In these cases it seems better to force the constant into a register and use a normal store: lhi %r2, 4 stc %r2, 0(%r3, %r4) since %r2 is more likely to be hoisted and is easier to rematerialize. llvm-svn: 189098
2013-08-23 19:18:53 +08:00
: InstSIL<opcode, (outs), (ins mviaddr12pair:$BD1, imm:$I2),
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
mnemonic#"\t$BD1, $I2",
[SystemZ] Prefer LHI;ST... over LAY;MV... If we had a store of an integer to memory, and the integer and store size were suitable for a form of MV..., we used MV... no matter what. We could then have sequences like: lay %r2, 0(%r3,%r4) mvi 0(%r2), 4 In these cases it seems better to force the constant into a register and use a normal store: lhi %r2, 4 stc %r2, 0(%r3, %r4) since %r2 is more likely to be hoisted and is easier to rematerialize. llvm-svn: 189098
2013-08-23 19:18:53 +08:00
[(operator imm:$I2, mviaddr12pair:$BD1)]> {
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayStore = 1;
}
multiclass StoreSIPair<string mnemonic, bits<8> siOpcode, bits<16> siyOpcode,
SDPatternOperator operator, Immediate imm> {
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispKey = mnemonic in {
let DispSize = "12" in
[SystemZ] Prefer LHI;ST... over LAY;MV... If we had a store of an integer to memory, and the integer and store size were suitable for a form of MV..., we used MV... no matter what. We could then have sequences like: lay %r2, 0(%r3,%r4) mvi 0(%r2), 4 In these cases it seems better to force the constant into a register and use a normal store: lhi %r2, 4 stc %r2, 0(%r3, %r4) since %r2 is more likely to be hoisted and is easier to rematerialize. llvm-svn: 189098
2013-08-23 19:18:53 +08:00
def "" : StoreSI<mnemonic, siOpcode, operator, imm>;
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispSize = "20" in
[SystemZ] Prefer LHI;ST... over LAY;MV... If we had a store of an integer to memory, and the integer and store size were suitable for a form of MV..., we used MV... no matter what. We could then have sequences like: lay %r2, 0(%r3,%r4) mvi 0(%r2), 4 In these cases it seems better to force the constant into a register and use a normal store: lhi %r2, 4 stc %r2, 0(%r3, %r4) since %r2 is more likely to be hoisted and is easier to rematerialize. llvm-svn: 189098
2013-08-23 19:18:53 +08:00
def Y : StoreSIY<mnemonic#"y", siyOpcode, operator, imm>;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
}
[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 16:57:02 +08:00
class CondStoreRSY<string mnemonic, bits<16> opcode,
RegisterOperand cls, bits<5> bytes,
AddressingMode mode = bdaddr20only>
[SystemZ] Reuse CC results for integer comparisons with zero 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
2013-08-01 18:39:40 +08:00
: InstRSY<opcode, (outs), (ins cls:$R1, mode:$BD2, cond4:$valid, cond4:$R3),
[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 16:57:02 +08:00
mnemonic#"$R3\t$R1, $BD2", []>,
Requires<[FeatureLoadStoreOnCond]> {
let mayStore = 1;
let AccessBytes = bytes;
[SystemZ] Reuse CC results for integer comparisons with zero 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
2013-08-01 18:39:40 +08:00
let CCMaskLast = 1;
[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 16:57:02 +08:00
}
// Like CondStoreRSY, but used for the raw assembly form. The condition-code
// mask is the third operand rather than being part of the mnemonic.
class AsmCondStoreRSY<string mnemonic, bits<16> opcode,
RegisterOperand cls, bits<5> bytes,
AddressingMode mode = bdaddr20only>
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
: InstRSY<opcode, (outs), (ins cls:$R1, mode:$BD2, imm32zx4:$R3),
[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 16:57:02 +08:00
mnemonic#"\t$R1, $BD2, $R3", []>,
Requires<[FeatureLoadStoreOnCond]> {
let mayStore = 1;
let AccessBytes = bytes;
}
// Like CondStoreRSY, but with a fixed CC mask.
class FixedCondStoreRSY<string mnemonic, bits<16> opcode,
RegisterOperand cls, bits<4> ccmask, bits<5> bytes,
AddressingMode mode = bdaddr20only>
: InstRSY<opcode, (outs), (ins cls:$R1, mode:$BD2),
mnemonic#"\t$R1, $BD2", []>,
Requires<[FeatureLoadStoreOnCond]> {
let mayStore = 1;
let AccessBytes = bytes;
let R3 = ccmask;
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class UnaryRR<string mnemonic, bits<8> opcode, SDPatternOperator operator,
RegisterOperand cls1, RegisterOperand cls2>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRR<opcode, (outs cls1:$R1), (ins cls2:$R2),
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
mnemonic#"r\t$R1, $R2",
[(set cls1:$R1, (operator cls2:$R2))]> {
let OpKey = mnemonic ## cls1;
let OpType = "reg";
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class UnaryRRE<string mnemonic, bits<16> opcode, SDPatternOperator operator,
RegisterOperand cls1, RegisterOperand cls2>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRRE<opcode, (outs cls1:$R1), (ins cls2:$R2),
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
mnemonic#"r\t$R1, $R2",
[(set cls1:$R1, (operator cls2:$R2))]> {
let OpKey = mnemonic ## cls1;
let OpType = "reg";
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class UnaryRRF<string mnemonic, bits<16> opcode, RegisterOperand cls1,
RegisterOperand cls2>
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
: InstRRF<opcode, (outs cls1:$R1), (ins imm32zx4:$R3, cls2:$R2),
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
mnemonic#"r\t$R1, $R3, $R2", []> {
let OpKey = mnemonic ## cls1;
let OpType = "reg";
[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 16:58:08 +08:00
let R4 = 0;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
[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 16:58:08 +08:00
class UnaryRRF4<string mnemonic, bits<16> opcode, RegisterOperand cls1,
RegisterOperand cls2>
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
: InstRRF<opcode, (outs cls1:$R1), (ins imm32zx4:$R3, cls2:$R2, imm32zx4:$R4),
[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 16:58:08 +08:00
mnemonic#"\t$R1, $R3, $R2, $R4", []>;
[SystemZ] Add LOCR and LOCGR llvm-svn: 187113
2013-07-25 17:11:15 +08:00
// These instructions are generated by if conversion. The old value of R1
// is added as an implicit use.
class CondUnaryRRF<string mnemonic, bits<16> opcode, RegisterOperand cls1,
RegisterOperand cls2>
[SystemZ] Be more careful about inverting CC masks 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
2013-07-31 20:30:20 +08:00
: InstRRF<opcode, (outs cls1:$R1), (ins cls2:$R2, cond4:$valid, cond4:$R3),
[SystemZ] Add LOCR and LOCGR llvm-svn: 187113
2013-07-25 17:11:15 +08:00
mnemonic#"r$R3\t$R1, $R2", []>,
[SystemZ] Reuse CC results for integer comparisons with zero 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
2013-08-01 18:39:40 +08:00
Requires<[FeatureLoadStoreOnCond]> {
let CCMaskLast = 1;
[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 16:58:08 +08:00
let R4 = 0;
[SystemZ] Reuse CC results for integer comparisons with zero 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
2013-08-01 18:39:40 +08:00
}
[SystemZ] Add LOCR and LOCGR llvm-svn: 187113
2013-07-25 17:11:15 +08:00
// Like CondUnaryRRF, but used for the raw assembly form. The condition-code
// mask is the third operand rather than being part of the mnemonic.
class AsmCondUnaryRRF<string mnemonic, bits<16> opcode, RegisterOperand cls1,
RegisterOperand cls2>
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
: InstRRF<opcode, (outs cls1:$R1), (ins cls1:$R1src, cls2:$R2, imm32zx4:$R3),
[SystemZ] Add LOCR and LOCGR llvm-svn: 187113
2013-07-25 17:11:15 +08:00
mnemonic#"r\t$R1, $R2, $R3", []>,
Requires<[FeatureLoadStoreOnCond]> {
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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 16:58:08 +08:00
let R4 = 0;
[SystemZ] Add LOCR and LOCGR llvm-svn: 187113
2013-07-25 17:11:15 +08:00
}
// Like CondUnaryRRF, but with a fixed CC mask.
class FixedCondUnaryRRF<string mnemonic, bits<16> opcode, RegisterOperand cls1,
RegisterOperand cls2, bits<4> ccmask>
: InstRRF<opcode, (outs cls1:$R1), (ins cls1:$R1src, cls2:$R2),
mnemonic#"\t$R1, $R2", []>,
Requires<[FeatureLoadStoreOnCond]> {
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
let R3 = ccmask;
[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 16:58:08 +08:00
let R4 = 0;
[SystemZ] Add LOCR and LOCGR llvm-svn: 187113
2013-07-25 17:11:15 +08:00
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class UnaryRI<string mnemonic, bits<12> opcode, SDPatternOperator operator,
RegisterOperand cls, Immediate imm>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRI<opcode, (outs cls:$R1), (ins imm:$I2),
mnemonic#"\t$R1, $I2",
[(set cls:$R1, (operator imm:$I2))]>;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class UnaryRIL<string mnemonic, bits<12> opcode, SDPatternOperator operator,
RegisterOperand cls, Immediate imm>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRIL<opcode, (outs cls:$R1), (ins imm:$I2),
mnemonic#"\t$R1, $I2",
[(set cls:$R1, (operator imm:$I2))]>;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class UnaryRILPC<string mnemonic, bits<12> opcode, SDPatternOperator operator,
RegisterOperand cls>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRIL<opcode, (outs cls:$R1), (ins pcrel32:$I2),
mnemonic#"\t$R1, $I2",
[(set cls:$R1, (operator pcrel32:$I2))]> {
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
// We want PC-relative addresses to be tried ahead of BD and BDX addresses.
// However, BDXs have two extra operands and are therefore 6 units more
// complex.
let AddedComplexity = 7;
}
[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 17:04:52 +08:00
class CondUnaryRSY<string mnemonic, bits<16> opcode,
[SystemZ] Be more careful about inverting CC masks (conditional loads) Extend r187495 to conditional loads. I split this out because the easiest way seemed to be to force a particular operand order in SystemZISelDAGToDAG.cpp. llvm-svn: 187496
2013-07-31 20:38:08 +08:00
SDPatternOperator operator, RegisterOperand cls,
bits<5> bytes, AddressingMode mode = bdaddr20only>
: InstRSY<opcode, (outs cls:$R1),
(ins cls:$R1src, mode:$BD2, cond4:$valid, cond4:$R3),
mnemonic#"$R3\t$R1, $BD2",
[(set cls:$R1,
(z_select_ccmask (load bdaddr20only:$BD2), cls:$R1src,
cond4:$valid, cond4:$R3))]>,
[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 17:04:52 +08:00
Requires<[FeatureLoadStoreOnCond]> {
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
let mayLoad = 1;
let AccessBytes = bytes;
[SystemZ] Reuse CC results for integer comparisons with zero 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
2013-08-01 18:39:40 +08:00
let CCMaskLast = 1;
[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 17:04:52 +08:00
}
// Like CondUnaryRSY, but used for the raw assembly form. The condition-code
// mask is the third operand rather than being part of the mnemonic.
class AsmCondUnaryRSY<string mnemonic, bits<16> opcode,
RegisterOperand cls, bits<5> bytes,
AddressingMode mode = bdaddr20only>
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
: InstRSY<opcode, (outs cls:$R1), (ins cls:$R1src, mode:$BD2, imm32zx4:$R3),
[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 17:04:52 +08:00
mnemonic#"\t$R1, $BD2, $R3", []>,
Requires<[FeatureLoadStoreOnCond]> {
let mayLoad = 1;
let AccessBytes = bytes;
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
}
// Like CondUnaryRSY, but with a fixed CC mask.
class FixedCondUnaryRSY<string mnemonic, bits<16> opcode,
RegisterOperand cls, bits<4> ccmask, bits<5> bytes,
AddressingMode mode = bdaddr20only>
: InstRSY<opcode, (outs cls:$R1), (ins cls:$R1src, mode:$BD2),
mnemonic#"\t$R1, $BD2", []>,
Requires<[FeatureLoadStoreOnCond]> {
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
let R3 = ccmask;
let mayLoad = 1;
let AccessBytes = bytes;
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class UnaryRX<string mnemonic, bits<8> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, bits<5> bytes,
AddressingMode mode = bdxaddr12only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRX<opcode, (outs cls:$R1), (ins mode:$XBD2),
mnemonic#"\t$R1, $XBD2",
[(set cls:$R1, (operator mode:$XBD2))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
class UnaryRXE<string mnemonic, bits<16> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, bits<5> bytes>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRXE<opcode, (outs cls:$R1), (ins bdxaddr12only:$XBD2),
mnemonic#"\t$R1, $XBD2",
[(set cls:$R1, (operator bdxaddr12only:$XBD2))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
let M3 = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
class UnaryRXY<string mnemonic, bits<16> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, bits<5> bytes,
AddressingMode mode = bdxaddr20only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRXY<opcode, (outs cls:$R1), (ins mode:$XBD2),
mnemonic#"\t$R1, $XBD2",
[(set cls:$R1, (operator mode:$XBD2))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
multiclass UnaryRXPair<string mnemonic, bits<8> rxOpcode, bits<16> rxyOpcode,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
SDPatternOperator operator, RegisterOperand cls,
bits<5> bytes> {
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispKey = mnemonic ## #cls in {
let DispSize = "12" in
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
def "" : UnaryRX<mnemonic, rxOpcode, operator, cls, bytes, bdxaddr12pair>;
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispSize = "20" in
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
def Y : UnaryRXY<mnemonic#"y", rxyOpcode, operator, cls, bytes,
bdxaddr20pair>;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
}
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
class UnaryVRIa<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr, Immediate imm, bits<4> type = 0>
: InstVRIa<opcode, (outs tr.op:$V1), (ins imm:$I2),
mnemonic#"\t$V1, $I2",
[(set tr.op:$V1, (tr.vt (operator imm:$I2)))]> {
let M3 = type;
}
class UnaryVRRa<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> type = 0, bits<4> m4 = 0,
bits<4> m5 = 0>
: InstVRRa<opcode, (outs tr1.op:$V1), (ins tr2.op:$V2),
mnemonic#"\t$V1, $V2",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2))))]> {
let M3 = type;
let M4 = m4;
let M5 = m5;
}
multiclass UnaryVRRaSPair<string mnemonic, bits<16> opcode,
SDPatternOperator operator,
SDPatternOperator operator_cc, TypedReg tr1,
TypedReg tr2, bits<4> type, bits<4> modifier = 0,
bits<4> modifier_cc = 1> {
def "" : UnaryVRRa<mnemonic, opcode, operator, tr1, tr2, type, 0, modifier>;
let Defs = [CC] in
def S : UnaryVRRa<mnemonic##"s", opcode, operator_cc, tr1, tr2, type, 0,
modifier_cc>;
}
class UnaryVRX<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr, bits<5> bytes, bits<4> type = 0>
: InstVRX<opcode, (outs tr.op:$V1), (ins bdxaddr12only:$XBD2),
mnemonic#"\t$V1, $XBD2",
[(set tr.op:$V1, (tr.vt (operator bdxaddr12only:$XBD2)))]> {
let M3 = type;
let mayLoad = 1;
let AccessBytes = bytes;
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class BinaryRR<string mnemonic, bits<8> opcode, SDPatternOperator operator,
RegisterOperand cls1, RegisterOperand cls2>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRR<opcode, (outs cls1:$R1), (ins cls1:$R1src, cls2:$R2),
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
mnemonic#"r\t$R1, $R2",
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
[(set cls1:$R1, (operator cls1:$R1src, cls2:$R2))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls1;
let OpType = "reg";
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
class BinaryRRE<string mnemonic, bits<16> opcode, SDPatternOperator operator,
RegisterOperand cls1, RegisterOperand cls2>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRRE<opcode, (outs cls1:$R1), (ins cls1:$R1src, cls2:$R2),
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
mnemonic#"r\t$R1, $R2",
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
[(set cls1:$R1, (operator cls1:$R1src, cls2:$R2))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls1;
let OpType = "reg";
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
class BinaryRRF<string mnemonic, bits<16> opcode, SDPatternOperator operator,
RegisterOperand cls1, RegisterOperand cls2>
: InstRRF<opcode, (outs cls1:$R1), (ins cls1:$R3, cls2:$R2),
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
mnemonic#"r\t$R1, $R3, $R2",
[(set cls1:$R1, (operator cls1:$R3, cls2:$R2))]> {
let OpKey = mnemonic ## cls1;
let OpType = "reg";
[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 16:58:08 +08:00
let R4 = 0;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
[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-20 00:21:55 +08:00
class BinaryRRFK<string mnemonic, bits<16> opcode, SDPatternOperator operator,
RegisterOperand cls1, RegisterOperand cls2>
: InstRRF<opcode, (outs cls1:$R1), (ins cls1:$R2, cls2:$R3),
mnemonic#"rk\t$R1, $R2, $R3",
[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 16:58:08 +08:00
[(set cls1:$R1, (operator cls1:$R2, cls2:$R3))]> {
let R4 = 0;
}
[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-20 00:21:55 +08:00
multiclass BinaryRRAndK<string mnemonic, bits<8> opcode1, bits<16> opcode2,
SDPatternOperator operator, RegisterOperand cls1,
RegisterOperand cls2> {
let NumOpsKey = mnemonic in {
let NumOpsValue = "3" in
def K : BinaryRRFK<mnemonic, opcode2, null_frag, cls1, cls2>,
Requires<[FeatureDistinctOps]>;
let NumOpsValue = "2", isConvertibleToThreeAddress = 1 in
def "" : BinaryRR<mnemonic, opcode1, operator, cls1, cls2>;
}
}
[SystemZ] Add NGRK, OGRK and XGRK Like r186683, but for 64 bits. llvm-svn: 186685
2013-07-20 00:24:22 +08:00
multiclass BinaryRREAndK<string mnemonic, bits<16> opcode1, bits<16> opcode2,
SDPatternOperator operator, RegisterOperand cls1,
RegisterOperand cls2> {
let NumOpsKey = mnemonic in {
let NumOpsValue = "3" in
def K : BinaryRRFK<mnemonic, opcode2, null_frag, cls1, cls2>,
Requires<[FeatureDistinctOps]>;
let NumOpsValue = "2", isConvertibleToThreeAddress = 1 in
def "" : BinaryRRE<mnemonic, opcode1, operator, cls1, cls2>;
}
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class BinaryRI<string mnemonic, bits<12> opcode, SDPatternOperator operator,
RegisterOperand cls, Immediate imm>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRI<opcode, (outs cls:$R1), (ins cls:$R1src, imm:$I2),
mnemonic#"\t$R1, $I2",
[(set cls:$R1, (operator cls:$R1src, imm:$I2))]> {
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
[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-20 00:32:12 +08:00
class BinaryRIE<string mnemonic, bits<16> opcode, SDPatternOperator operator,
RegisterOperand cls, Immediate imm>
: InstRIEd<opcode, (outs cls:$R1), (ins cls:$R3, imm:$I2),
mnemonic#"\t$R1, $R3, $I2",
[(set cls:$R1, (operator cls:$R3, imm:$I2))]>;
multiclass BinaryRIAndK<string mnemonic, bits<12> opcode1, bits<16> opcode2,
SDPatternOperator operator, RegisterOperand cls,
Immediate imm> {
let NumOpsKey = mnemonic in {
let NumOpsValue = "3" in
def K : BinaryRIE<mnemonic##"k", opcode2, null_frag, cls, imm>,
Requires<[FeatureDistinctOps]>;
let NumOpsValue = "2", isConvertibleToThreeAddress = 1 in
def "" : BinaryRI<mnemonic, opcode1, operator, cls, imm>;
}
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class BinaryRIL<string mnemonic, bits<12> opcode, SDPatternOperator operator,
RegisterOperand cls, Immediate imm>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRIL<opcode, (outs cls:$R1), (ins cls:$R1src, imm:$I2),
mnemonic#"\t$R1, $I2",
[(set cls:$R1, (operator cls:$R1src, imm:$I2))]> {
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
[SystemZ] Tweak instruction format classifications There's no real need to have Shift as a separate format type from Binary. The comments for other format types were too specific and in some cases no longer accurate. Just a clean-up, no behavioral change intended. llvm-svn: 212707
2014-07-10 19:29:23 +08:00
class BinaryRS<string mnemonic, bits<8> opcode, SDPatternOperator operator,
RegisterOperand cls>
: InstRS<opcode, (outs cls:$R1), (ins cls:$R1src, shift12only:$BD2),
mnemonic#"\t$R1, $BD2",
[(set cls:$R1, (operator cls:$R1src, shift12only:$BD2))]> {
let R3 = 0;
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
}
class BinaryRSY<string mnemonic, bits<16> opcode, SDPatternOperator operator,
RegisterOperand cls>
: InstRSY<opcode, (outs cls:$R1), (ins cls:$R3, shift20only:$BD2),
mnemonic#"\t$R1, $R3, $BD2",
[(set cls:$R1, (operator cls:$R3, shift20only:$BD2))]>;
multiclass BinaryRSAndK<string mnemonic, bits<8> opcode1, bits<16> opcode2,
SDPatternOperator operator, RegisterOperand cls> {
let NumOpsKey = mnemonic in {
let NumOpsValue = "3" in
def K : BinaryRSY<mnemonic##"k", opcode2, null_frag, cls>,
Requires<[FeatureDistinctOps]>;
let NumOpsValue = "2", isConvertibleToThreeAddress = 1 in
def "" : BinaryRS<mnemonic, opcode1, operator, cls>;
}
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class BinaryRX<string mnemonic, bits<8> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, SDPatternOperator load, bits<5> bytes,
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
AddressingMode mode = bdxaddr12only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRX<opcode, (outs cls:$R1), (ins cls:$R1src, mode:$XBD2),
mnemonic#"\t$R1, $XBD2",
[(set cls:$R1, (operator cls:$R1src, (load mode:$XBD2)))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
class BinaryRXE<string mnemonic, bits<16> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, SDPatternOperator load, bits<5> bytes>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRXE<opcode, (outs cls:$R1), (ins cls:$R1src, bdxaddr12only:$XBD2),
mnemonic#"\t$R1, $XBD2",
[(set cls:$R1, (operator cls:$R1src,
(load bdxaddr12only:$XBD2)))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
let M3 = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
class BinaryRXY<string mnemonic, bits<16> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, SDPatternOperator load, bits<5> bytes,
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
AddressingMode mode = bdxaddr20only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRXY<opcode, (outs cls:$R1), (ins cls:$R1src, mode:$XBD2),
mnemonic#"\t$R1, $XBD2",
[(set cls:$R1, (operator cls:$R1src, (load mode:$XBD2)))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
multiclass BinaryRXPair<string mnemonic, bits<8> rxOpcode, bits<16> rxyOpcode,
SDPatternOperator operator, RegisterOperand cls,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
SDPatternOperator load, bits<5> bytes> {
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispKey = mnemonic ## #cls in {
let DispSize = "12" in
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
def "" : BinaryRX<mnemonic, rxOpcode, operator, cls, load, bytes,
bdxaddr12pair>;
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispSize = "20" in
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
def Y : BinaryRXY<mnemonic#"y", rxyOpcode, operator, cls, load, bytes,
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
bdxaddr20pair>;
}
}
class BinarySI<string mnemonic, bits<8> opcode, SDPatternOperator operator,
Operand imm, AddressingMode mode = bdaddr12only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstSI<opcode, (outs), (ins mode:$BD1, imm:$I2),
mnemonic#"\t$BD1, $I2",
[(store (operator (load mode:$BD1), imm:$I2), mode:$BD1)]> {
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
let mayStore = 1;
}
class BinarySIY<string mnemonic, bits<16> opcode, SDPatternOperator operator,
Operand imm, AddressingMode mode = bdaddr20only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstSIY<opcode, (outs), (ins mode:$BD1, imm:$I2),
mnemonic#"\t$BD1, $I2",
[(store (operator (load mode:$BD1), imm:$I2), mode:$BD1)]> {
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
let mayStore = 1;
}
multiclass BinarySIPair<string mnemonic, bits<8> siOpcode,
bits<16> siyOpcode, SDPatternOperator operator,
Operand imm> {
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispKey = mnemonic ## #cls in {
let DispSize = "12" in
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
def "" : BinarySI<mnemonic, siOpcode, operator, imm, bdaddr12pair>;
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispSize = "20" in
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
def Y : BinarySIY<mnemonic#"y", siyOpcode, operator, imm, bdaddr20pair>;
}
}
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
class BinaryVRIb<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr, bits<4> type>
: InstVRIb<opcode, (outs tr.op:$V1), (ins imm32zx8:$I2, imm32zx8:$I3),
mnemonic#"\t$V1, $I2, $I3",
[(set tr.op:$V1, (tr.vt (operator imm32zx8:$I2, imm32zx8:$I3)))]> {
let M4 = type;
}
class BinaryVRIc<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> type>
: InstVRIc<opcode, (outs tr1.op:$V1), (ins tr2.op:$V3, imm32zx16:$I2),
mnemonic#"\t$V1, $V3, $I2",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V3),
imm32zx16:$I2)))]> {
let M4 = type;
}
class BinaryVRIe<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> type, bits<4> m5>
: InstVRIe<opcode, (outs tr1.op:$V1), (ins tr2.op:$V2, imm32zx12:$I3),
mnemonic#"\t$V1, $V2, $I3",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2),
imm32zx12:$I3)))]> {
let M4 = type;
let M5 = m5;
}
class BinaryVRRa<string mnemonic, bits<16> opcode>
: InstVRRa<opcode, (outs VR128:$V1), (ins VR128:$V2, imm32zx4:$M3),
mnemonic#"\t$V1, $V2, $M3", []> {
let M4 = 0;
let M5 = 0;
}
class BinaryVRRb<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> type = 0,
bits<4> modifier = 0>
: InstVRRb<opcode, (outs tr1.op:$V1), (ins tr2.op:$V2, tr2.op:$V3),
mnemonic#"\t$V1, $V2, $V3",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2),
(tr2.vt tr2.op:$V3))))]> {
let M4 = type;
let M5 = modifier;
}
// Declare a pair of instructions, one which sets CC and one which doesn't.
// The CC-setting form ends with "S" and sets the low bit of M5.
multiclass BinaryVRRbSPair<string mnemonic, bits<16> opcode,
SDPatternOperator operator,
SDPatternOperator operator_cc, TypedReg tr1,
TypedReg tr2, bits<4> type,
bits<4> modifier = 0, bits<4> modifier_cc = 1> {
def "" : BinaryVRRb<mnemonic, opcode, operator, tr1, tr2, type, modifier>;
let Defs = [CC] in
def S : BinaryVRRb<mnemonic##"s", opcode, operator_cc, tr1, tr2, type,
modifier_cc>;
}
class BinaryVRRc<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> type = 0, bits<4> m5 = 0,
bits<4> m6 = 0>
: InstVRRc<opcode, (outs tr1.op:$V1), (ins tr2.op:$V2, tr2.op:$V3),
mnemonic#"\t$V1, $V2, $V3",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2),
(tr2.vt tr2.op:$V3))))]> {
let M4 = type;
let M5 = m5;
let M6 = m6;
}
multiclass BinaryVRRcSPair<string mnemonic, bits<16> opcode,
SDPatternOperator operator,
SDPatternOperator operator_cc, TypedReg tr1,
TypedReg tr2, bits<4> type, bits<4> m5,
bits<4> modifier = 0, bits<4> modifier_cc = 1> {
def "" : BinaryVRRc<mnemonic, opcode, operator, tr1, tr2, type, m5, modifier>;
let Defs = [CC] in
def S : BinaryVRRc<mnemonic##"s", opcode, operator_cc, tr1, tr2, type,
m5, modifier_cc>;
}
class BinaryVRRf<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr>
: InstVRRf<opcode, (outs tr.op:$V1), (ins GR64:$R2, GR64:$R3),
mnemonic#"\t$V1, $R2, $R3",
[(set tr.op:$V1, (tr.vt (operator GR64:$R2, GR64:$R3)))]>;
class BinaryVRSa<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> type>
: InstVRSa<opcode, (outs tr1.op:$V1), (ins tr2.op:$V3, shift12only:$BD2),
mnemonic#"\t$V1, $V3, $BD2",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V3),
shift12only:$BD2)))]> {
let M4 = type;
}
class BinaryVRSb<string mnemonic, bits<16> opcode, SDPatternOperator operator,
bits<5> bytes>
: InstVRSb<opcode, (outs VR128:$V1), (ins GR32:$R3, bdaddr12only:$BD2),
mnemonic#"\t$V1, $R3, $BD2",
[(set VR128:$V1, (operator GR32:$R3, bdaddr12only:$BD2))]> {
let M4 = 0;
let mayLoad = 1;
let AccessBytes = bytes;
}
class BinaryVRSc<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr, bits<4> type>
: InstVRSc<opcode, (outs GR64:$R1), (ins tr.op:$V3, shift12only:$BD2),
mnemonic#"\t$R1, $V3, $BD2",
[(set GR64:$R1, (operator (tr.vt tr.op:$V3), shift12only:$BD2))]> {
let M4 = type;
}
class BinaryVRX<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr, bits<5> bytes>
: InstVRX<opcode, (outs VR128:$V1), (ins bdxaddr12only:$XBD2, imm32zx4:$M3),
mnemonic#"\t$V1, $XBD2, $M3",
[(set tr.op:$V1, (tr.vt (operator bdxaddr12only:$XBD2,
imm32zx4:$M3)))]> {
let mayLoad = 1;
let AccessBytes = bytes;
}
class StoreBinaryVRV<string mnemonic, bits<16> opcode, bits<5> bytes,
Immediate index>
: InstVRV<opcode, (outs), (ins VR128:$V1, bdvaddr12only:$VBD2, index:$M3),
mnemonic#"\t$V1, $VBD2, $M3", []> {
let mayStore = 1;
let AccessBytes = bytes;
}
class StoreBinaryVRX<string mnemonic, bits<16> opcode,
SDPatternOperator operator, TypedReg tr, bits<5> bytes,
Immediate index>
: InstVRX<opcode, (outs), (ins tr.op:$V1, bdxaddr12only:$XBD2, index:$M3),
mnemonic#"\t$V1, $XBD2, $M3",
[(operator (tr.vt tr.op:$V1), bdxaddr12only:$XBD2, index:$M3)]> {
let mayStore = 1;
let AccessBytes = bytes;
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class CompareRR<string mnemonic, bits<8> opcode, SDPatternOperator operator,
RegisterOperand cls1, RegisterOperand cls2>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRR<opcode, (outs), (ins cls1:$R1, cls2:$R2),
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
mnemonic#"r\t$R1, $R2",
[(operator cls1:$R1, cls2:$R2)]> {
let OpKey = mnemonic ## cls1;
let OpType = "reg";
[SystemZ] Rework compare and branch support 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
2013-07-25 17:34:38 +08:00
let isCompare = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class CompareRRE<string mnemonic, bits<16> opcode, SDPatternOperator operator,
RegisterOperand cls1, RegisterOperand cls2>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRRE<opcode, (outs), (ins cls1:$R1, cls2:$R2),
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
mnemonic#"r\t$R1, $R2",
[(operator cls1:$R1, cls2:$R2)]> {
let OpKey = mnemonic ## cls1;
let OpType = "reg";
[SystemZ] Rework compare and branch support 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
2013-07-25 17:34:38 +08:00
let isCompare = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class CompareRI<string mnemonic, bits<12> opcode, SDPatternOperator operator,
RegisterOperand cls, Immediate imm>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRI<opcode, (outs), (ins cls:$R1, imm:$I2),
mnemonic#"\t$R1, $I2",
[SystemZ] Rework compare and branch support 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
2013-07-25 17:34:38 +08:00
[(operator cls:$R1, imm:$I2)]> {
let isCompare = 1;
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class CompareRIL<string mnemonic, bits<12> opcode, SDPatternOperator operator,
RegisterOperand cls, Immediate imm>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRIL<opcode, (outs), (ins cls:$R1, imm:$I2),
mnemonic#"\t$R1, $I2",
[SystemZ] Rework compare and branch support 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
2013-07-25 17:34:38 +08:00
[(operator cls:$R1, imm:$I2)]> {
let isCompare = 1;
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class CompareRILPC<string mnemonic, bits<12> opcode, SDPatternOperator operator,
RegisterOperand cls, SDPatternOperator load>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRIL<opcode, (outs), (ins cls:$R1, pcrel32:$I2),
mnemonic#"\t$R1, $I2",
[(operator cls:$R1, (load pcrel32:$I2))]> {
[SystemZ] Rework compare and branch support 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
2013-07-25 17:34:38 +08:00
let isCompare = 1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
// We want PC-relative addresses to be tried ahead of BD and BDX addresses.
// However, BDXs have two extra operands and are therefore 6 units more
// complex.
let AddedComplexity = 7;
}
class CompareRX<string mnemonic, bits<8> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, SDPatternOperator load, bits<5> bytes,
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
AddressingMode mode = bdxaddr12only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRX<opcode, (outs), (ins cls:$R1, mode:$XBD2),
mnemonic#"\t$R1, $XBD2",
[(operator cls:$R1, (load mode:$XBD2))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[SystemZ] Rework compare and branch support 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
2013-07-25 17:34:38 +08:00
let isCompare = 1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
class CompareRXE<string mnemonic, bits<16> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, SDPatternOperator load, bits<5> bytes>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRXE<opcode, (outs), (ins cls:$R1, bdxaddr12only:$XBD2),
mnemonic#"\t$R1, $XBD2",
[(operator cls:$R1, (load bdxaddr12only:$XBD2))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[SystemZ] Rework compare and branch support 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
2013-07-25 17:34:38 +08:00
let isCompare = 1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
let M3 = 0;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
class CompareRXY<string mnemonic, bits<16> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, SDPatternOperator load, bits<5> bytes,
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
AddressingMode mode = bdxaddr20only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRXY<opcode, (outs), (ins cls:$R1, mode:$XBD2),
mnemonic#"\t$R1, $XBD2",
[(operator cls:$R1, (load mode:$XBD2))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[SystemZ] Rework compare and branch support 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
2013-07-25 17:34:38 +08:00
let isCompare = 1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
multiclass CompareRXPair<string mnemonic, bits<8> rxOpcode, bits<16> rxyOpcode,
SDPatternOperator operator, RegisterOperand cls,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
SDPatternOperator load, bits<5> bytes> {
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispKey = mnemonic ## #cls in {
let DispSize = "12" in
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
def "" : CompareRX<mnemonic, rxOpcode, operator, cls,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
load, bytes, bdxaddr12pair>;
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispSize = "20" in
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
def Y : CompareRXY<mnemonic#"y", rxyOpcode, operator, cls,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
load, bytes, bdxaddr20pair>;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
}
class CompareSI<string mnemonic, bits<8> opcode, SDPatternOperator operator,
SDPatternOperator load, Immediate imm,
AddressingMode mode = bdaddr12only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstSI<opcode, (outs), (ins mode:$BD1, imm:$I2),
mnemonic#"\t$BD1, $I2",
[(operator (load mode:$BD1), imm:$I2)]> {
[SystemZ] Rework compare and branch support 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
2013-07-25 17:34:38 +08:00
let isCompare = 1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
}
class CompareSIL<string mnemonic, bits<16> opcode, SDPatternOperator operator,
SDPatternOperator load, Immediate imm>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstSIL<opcode, (outs), (ins bdaddr12only:$BD1, imm:$I2),
mnemonic#"\t$BD1, $I2",
[(operator (load bdaddr12only:$BD1), imm:$I2)]> {
[SystemZ] Rework compare and branch support 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
2013-07-25 17:34:38 +08:00
let isCompare = 1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
}
class CompareSIY<string mnemonic, bits<16> opcode, SDPatternOperator operator,
SDPatternOperator load, Immediate imm,
AddressingMode mode = bdaddr20only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstSIY<opcode, (outs), (ins mode:$BD1, imm:$I2),
mnemonic#"\t$BD1, $I2",
[(operator (load mode:$BD1), imm:$I2)]> {
[SystemZ] Rework compare and branch support 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
2013-07-25 17:34:38 +08:00
let isCompare = 1;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
}
multiclass CompareSIPair<string mnemonic, bits<8> siOpcode, bits<16> siyOpcode,
SDPatternOperator operator, SDPatternOperator load,
Immediate imm> {
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispKey = mnemonic in {
let DispSize = "12" in
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
def "" : CompareSI<mnemonic, siOpcode, operator, load, imm, bdaddr12pair>;
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispSize = "20" in
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
def Y : CompareSIY<mnemonic#"y", siyOpcode, operator, load, imm,
bdaddr20pair>;
}
}
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
class CompareVRRa<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr, bits<4> type>
: InstVRRa<opcode, (outs), (ins tr.op:$V1, tr.op:$V2),
mnemonic#"\t$V1, $V2",
[(operator (tr.vt tr.op:$V1), (tr.vt tr.op:$V2))]> {
let isCompare = 1;
let M3 = type;
let M4 = 0;
let M5 = 0;
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class TernaryRRD<string mnemonic, bits<16> opcode,
SDPatternOperator operator, RegisterOperand cls>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRRD<opcode, (outs cls:$R1), (ins cls:$R1src, cls:$R3, cls:$R2),
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
mnemonic#"r\t$R1, $R3, $R2",
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
[(set cls:$R1, (operator cls:$R1src, cls:$R3, cls:$R2))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "reg";
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
class TernaryRXF<string mnemonic, bits<16> opcode, SDPatternOperator operator,
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
RegisterOperand cls, SDPatternOperator load, bits<5> bytes>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRXF<opcode, (outs cls:$R1),
(ins cls:$R1src, cls:$R3, bdxaddr12only:$XBD2),
mnemonic#"\t$R1, $R3, $XBD2",
[(set cls:$R1, (operator cls:$R1src, cls:$R3,
(load bdxaddr12only:$XBD2)))]> {
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let OpKey = mnemonic ## cls;
let OpType = "mem";
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
[SystemZ] Fold more spills 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
2013-07-03 18:10:02 +08:00
let AccessBytes = bytes;
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
[SystemZ] Add z13 vector facility and MC support This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
2015-05-06 03:23:40 +08:00
class TernaryVRIa<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, Immediate imm, Immediate index>
: InstVRIa<opcode, (outs tr1.op:$V1), (ins tr2.op:$V1src, imm:$I2, index:$M3),
mnemonic#"\t$V1, $I2, $M3",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V1src),
imm:$I2, index:$M3)))]> {
let Constraints = "$V1 = $V1src";
let DisableEncoding = "$V1src";
}
class TernaryVRId<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> type>
: InstVRId<opcode, (outs tr1.op:$V1),
(ins tr2.op:$V2, tr2.op:$V3, imm32zx8:$I4),
mnemonic#"\t$V1, $V2, $V3, $I4",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2),
(tr2.vt tr2.op:$V3),
imm32zx8:$I4)))]> {
let M5 = type;
}
class TernaryVRRa<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> type, bits<4> m4or>
: InstVRRa<opcode, (outs tr1.op:$V1),
(ins tr2.op:$V2, imm32zx4:$M4, imm32zx4:$M5),
mnemonic#"\t$V1, $V2, $M4, $M5",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2),
imm32zx4:$M4,
imm32zx4:$M5)))],
m4or> {
let M3 = type;
}
class TernaryVRRb<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> type,
SDPatternOperator m5mask, bits<4> m5or>
: InstVRRb<opcode, (outs tr1.op:$V1),
(ins tr2.op:$V2, tr2.op:$V3, m5mask:$M5),
mnemonic#"\t$V1, $V2, $V3, $M5",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2),
(tr2.vt tr2.op:$V3),
m5mask:$M5)))],
m5or> {
let M4 = type;
}
multiclass TernaryVRRbSPair<string mnemonic, bits<16> opcode,
SDPatternOperator operator,
SDPatternOperator operator_cc, TypedReg tr1,
TypedReg tr2, bits<4> type, bits<4> m5or> {
def "" : TernaryVRRb<mnemonic, opcode, operator, tr1, tr2, type,
imm32zx4even, !and (m5or, 14)>;
def : InstAlias<mnemonic#"\t$V1, $V2, $V3",
(!cast<Instruction>(NAME) tr1.op:$V1, tr2.op:$V2,
tr2.op:$V3, 0)>;
let Defs = [CC] in
def S : TernaryVRRb<mnemonic##"s", opcode, operator_cc, tr1, tr2, type,
imm32zx4even, !add(!and (m5or, 14), 1)>;
def : InstAlias<mnemonic#"s\t$V1, $V2, $V3",
(!cast<Instruction>(NAME#"S") tr1.op:$V1, tr2.op:$V2,
tr2.op:$V3, 0)>;
}
class TernaryVRRc<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2>
: InstVRRc<opcode, (outs tr1.op:$V1),
(ins tr2.op:$V2, tr2.op:$V3, imm32zx4:$M4),
mnemonic#"\t$V1, $V2, $V3, $M4",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2),
(tr2.vt tr2.op:$V3),
imm32zx4:$M4)))]> {
let M5 = 0;
let M6 = 0;
}
class TernaryVRRd<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> type = 0>
: InstVRRd<opcode, (outs tr1.op:$V1),
(ins tr2.op:$V2, tr2.op:$V3, tr1.op:$V4),
mnemonic#"\t$V1, $V2, $V3, $V4",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2),
(tr2.vt tr2.op:$V3),
(tr1.vt tr1.op:$V4))))]> {
let M5 = type;
let M6 = 0;
}
class TernaryVRRe<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> m5 = 0, bits<4> type = 0>
: InstVRRe<opcode, (outs tr1.op:$V1),
(ins tr2.op:$V2, tr2.op:$V3, tr1.op:$V4),
mnemonic#"\t$V1, $V2, $V3, $V4",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2),
(tr2.vt tr2.op:$V3),
(tr1.vt tr1.op:$V4))))]> {
let M5 = m5;
let M6 = type;
}
class TernaryVRSb<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, RegisterOperand cls, bits<4> type>
: InstVRSb<opcode, (outs tr1.op:$V1),
(ins tr2.op:$V1src, cls:$R3, shift12only:$BD2),
mnemonic#"\t$V1, $R3, $BD2",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V1src),
cls:$R3,
shift12only:$BD2)))]> {
let Constraints = "$V1 = $V1src";
let DisableEncoding = "$V1src";
let M4 = type;
}
class TernaryVRV<string mnemonic, bits<16> opcode, bits<5> bytes,
Immediate index>
: InstVRV<opcode, (outs VR128:$V1),
(ins VR128:$V1src, bdvaddr12only:$VBD2, index:$M3),
mnemonic#"\t$V1, $VBD2, $M3", []> {
let Constraints = "$V1 = $V1src";
let DisableEncoding = "$V1src";
let mayLoad = 1;
let AccessBytes = bytes;
}
class TernaryVRX<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<5> bytes, Immediate index>
: InstVRX<opcode, (outs tr1.op:$V1),
(ins tr2.op:$V1src, bdxaddr12only:$XBD2, index:$M3),
mnemonic#"\t$V1, $XBD2, $M3",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V1src),
bdxaddr12only:$XBD2,
index:$M3)))]> {
let Constraints = "$V1 = $V1src";
let DisableEncoding = "$V1src";
let mayLoad = 1;
let AccessBytes = bytes;
}
class QuaternaryVRId<string mnemonic, bits<16> opcode, SDPatternOperator operator,
TypedReg tr1, TypedReg tr2, bits<4> type>
: InstVRId<opcode, (outs tr1.op:$V1),
(ins tr2.op:$V1src, tr2.op:$V2, tr2.op:$V3, imm32zx8:$I4),
mnemonic#"\t$V1, $V2, $V3, $I4",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V1src),
(tr2.vt tr2.op:$V2),
(tr2.vt tr2.op:$V3),
imm32zx8:$I4)))]> {
let Constraints = "$V1 = $V1src";
let DisableEncoding = "$V1src";
let M5 = type;
}
class QuaternaryVRRd<string mnemonic, bits<16> opcode,
SDPatternOperator operator, TypedReg tr1, TypedReg tr2,
bits<4> type, SDPatternOperator m6mask, bits<4> m6or>
: InstVRRd<opcode, (outs tr1.op:$V1),
(ins tr2.op:$V2, tr2.op:$V3, tr2.op:$V4, m6mask:$M6),
mnemonic#"\t$V1, $V2, $V3, $V4, $M6",
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2),
(tr2.vt tr2.op:$V3),
(tr2.vt tr2.op:$V4),
m6mask:$M6)))],
m6or> {
let M5 = type;
}
multiclass QuaternaryVRRdSPair<string mnemonic, bits<16> opcode,
SDPatternOperator operator,
SDPatternOperator operator_cc, TypedReg tr1,
TypedReg tr2, bits<4> type, bits<4> m6or> {
def "" : QuaternaryVRRd<mnemonic, opcode, operator, tr1, tr2, type,
imm32zx4even, !and (m6or, 14)>;
def : InstAlias<mnemonic#"\t$V1, $V2, $V3, $V4",
(!cast<Instruction>(NAME) tr1.op:$V1, tr2.op:$V2,
tr2.op:$V3, tr2.op:$V4, 0)>;
let Defs = [CC] in
def S : QuaternaryVRRd<mnemonic##"s", opcode, operator_cc, tr1, tr2, type,
imm32zx4even, !add (!and (m6or, 14), 1)>;
def : InstAlias<mnemonic#"s\t$V1, $V2, $V3, $V4",
(!cast<Instruction>(NAME#"S") tr1.op:$V1, tr2.op:$V2,
tr2.op:$V3, tr2.op:$V4, 0)>;
}
[SystemZ] Add MC support for interlocked-access 1 instructions llvm-svn: 197984
2013-12-24 23:14:05 +08:00
class LoadAndOpRSY<string mnemonic, bits<16> opcode, SDPatternOperator operator,
RegisterOperand cls, AddressingMode mode = bdaddr20only>
: InstRSY<opcode, (outs cls:$R1), (ins cls:$R3, mode:$BD2),
mnemonic#"\t$R1, $R3, $BD2",
[(set cls:$R1, (operator mode:$BD2, cls:$R3))]> {
let mayLoad = 1;
let mayStore = 1;
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
class CmpSwapRS<string mnemonic, bits<8> opcode, SDPatternOperator operator,
RegisterOperand cls, AddressingMode mode = bdaddr12only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRS<opcode, (outs cls:$R1), (ins cls:$R1src, cls:$R3, mode:$BD2),
mnemonic#"\t$R1, $R3, $BD2",
[(set cls:$R1, (operator mode:$BD2, cls:$R1src, cls:$R3))]> {
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
let mayStore = 1;
}
class CmpSwapRSY<string mnemonic, bits<16> opcode, SDPatternOperator operator,
RegisterOperand cls, AddressingMode mode = bdaddr20only>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRSY<opcode, (outs cls:$R1), (ins cls:$R1src, cls:$R3, mode:$BD2),
mnemonic#"\t$R1, $R3, $BD2",
[(set cls:$R1, (operator mode:$BD2, cls:$R1src, cls:$R3))]> {
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let mayLoad = 1;
let mayStore = 1;
}
multiclass CmpSwapRSPair<string mnemonic, bits<8> rsOpcode, bits<16> rsyOpcode,
SDPatternOperator operator, RegisterOperand cls> {
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispKey = mnemonic ## #cls in {
let DispSize = "12" in
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
def "" : CmpSwapRS<mnemonic, rsOpcode, operator, cls, bdaddr12pair>;
[SystemZ] Rename mapping table fields 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
2013-07-03 17:19:58 +08:00
let DispSize = "20" in
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
def Y : CmpSwapRSY<mnemonic#"y", rsyOpcode, operator, cls, bdaddr20pair>;
}
}
class RotateSelectRIEf<string mnemonic, bits<16> opcode, RegisterOperand cls1,
RegisterOperand cls2>
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
: InstRIEf<opcode, (outs cls1:$R1),
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
(ins cls1:$R1src, cls2:$R2, imm32zx8:$I3, imm32zx8:$I4,
imm32zx6:$I5),
[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. llvm-svn: 181769
2013-05-14 17:28:21 +08:00
mnemonic#"\t$R1, $R2, $I3, $I4, $I5", []> {
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
[SystemZ] Add basic prefetch support Just the instructions and intrinsics for now. llvm-svn: 189100
2013-08-23 19:36:42 +08:00
class PrefetchRXY<string mnemonic, bits<16> opcode, SDPatternOperator operator>
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
: InstRXY<opcode, (outs), (ins imm32zx4:$R1, bdxaddr20only:$XBD2),
[SystemZ] Add basic prefetch support Just the instructions and intrinsics for now. llvm-svn: 189100
2013-08-23 19:36:42 +08:00
mnemonic##"\t$R1, $XBD2",
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
[(operator imm32zx4:$R1, bdxaddr20only:$XBD2)]>;
[SystemZ] Add basic prefetch support Just the instructions and intrinsics for now. llvm-svn: 189100
2013-08-23 19:36:42 +08:00
class PrefetchRILPC<string mnemonic, bits<12> opcode,
SDPatternOperator operator>
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
: InstRIL<opcode, (outs), (ins imm32zx4:$R1, pcrel32:$I2),
[SystemZ] Add basic prefetch support Just the instructions and intrinsics for now. llvm-svn: 189100
2013-08-23 19:36:42 +08:00
mnemonic##"\t$R1, $I2",
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
[(operator imm32zx4:$R1, pcrel32:$I2)]> {
[SystemZ] Add basic prefetch support Just the instructions and intrinsics for now. llvm-svn: 189100
2013-08-23 19:36:42 +08:00
// We want PC-relative addresses to be tried ahead of BD and BDX addresses.
// However, BDXs have two extra operands and are therefore 6 units more
// complex.
let AddedComplexity = 7;
}
[SystemZ] Add floating-point load-and-test instructions These instructions can also be used as comparisons with zero. llvm-svn: 187882
2013-08-07 19:03:34 +08:00
// A floating-point load-and test operation. Create both a normal unary
// operation and one that acts as a comparison against zero.
[SystemZ] Add CodeGen support for scalar f64 ops in vector registers 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
2015-05-06 03:28:34 +08:00
// Note that the comparison against zero operation is not available if we
// have vector support, since load-and-test instructions will partially
// clobber the target (vector) register.
[SystemZ] Add floating-point load-and-test instructions These instructions can also be used as comparisons with zero. llvm-svn: 187882
2013-08-07 19:03:34 +08:00
multiclass LoadAndTestRRE<string mnemonic, bits<16> opcode,
RegisterOperand cls> {
def "" : UnaryRRE<mnemonic, opcode, null_frag, cls, cls>;
[SystemZ] Add CodeGen support for scalar f64 ops in vector registers 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
2015-05-06 03:28:34 +08:00
let isCodeGenOnly = 1, Predicates = [FeatureNoVector] in
[SystemZ] Add floating-point load-and-test instructions These instructions can also be used as comparisons with zero. llvm-svn: 187882
2013-08-07 19:03:34 +08:00
def Compare : CompareRRE<mnemonic, opcode, null_frag, cls, cls>;
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
//===----------------------------------------------------------------------===//
// Pseudo instructions
//===----------------------------------------------------------------------===//
//
// Convenience instructions that get lowered to real instructions
// by either SystemZTargetLowering::EmitInstrWithCustomInserter()
// or SystemZInstrInfo::expandPostRAPseudo().
//
//===----------------------------------------------------------------------===//
class Pseudo<dag outs, dag ins, list<dag> pattern>
: InstSystemZ<0, outs, ins, "", pattern> {
let isPseudo = 1;
let isCodeGenOnly = 1;
}
[SystemZ] Add patterns to load a constant into a high word (IIHF) 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
2013-10-01 21:02:28 +08:00
// Like UnaryRI, but expanded after RA depending on the choice of register.
class UnaryRIPseudo<SDPatternOperator operator, RegisterOperand cls,
Immediate imm>
: Pseudo<(outs cls:$R1), (ins imm:$I2),
[(set cls:$R1, (operator imm:$I2))]>;
[SystemZ] Add comparisons of high words and memory llvm-svn: 191777
2013-10-01 23:00:44 +08:00
// Like UnaryRXY, but expanded after RA depending on the choice of register.
[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. llvm-svn: 191739
2013-10-01 19:26:28 +08:00
class UnaryRXYPseudo<string key, SDPatternOperator operator,
RegisterOperand cls, bits<5> bytes,
AddressingMode mode = bdxaddr20only>
: Pseudo<(outs cls:$R1), (ins mode:$XBD2),
[(set cls:$R1, (operator mode:$XBD2))]> {
let OpKey = key ## cls;
let OpType = "mem";
let mayLoad = 1;
let Has20BitOffset = 1;
let HasIndex = 1;
let AccessBytes = bytes;
}
// Like UnaryRR, but expanded after RA depending on the choice of registers.
class UnaryRRPseudo<string key, SDPatternOperator operator,
RegisterOperand cls1, RegisterOperand cls2>
: Pseudo<(outs cls1:$R1), (ins cls2:$R2),
[(set cls1:$R1, (operator cls2:$R2))]> {
let OpKey = key ## cls1;
let OpType = "reg";
}
[SystemZ] Allow integer insertions with a high-word destination llvm-svn: 191753
2013-10-01 21:18:56 +08:00
// Like BinaryRI, but expanded after RA depending on the choice of register.
class BinaryRIPseudo<SDPatternOperator operator, RegisterOperand cls,
Immediate imm>
: Pseudo<(outs cls:$R1), (ins cls:$R1src, imm:$I2),
[(set cls:$R1, (operator cls:$R1src, imm:$I2))]> {
let Constraints = "$R1 = $R1src";
}
[SystemZ] Add immediate addition involving high words llvm-svn: 191774
2013-10-01 22:53:46 +08:00
// Like BinaryRIE, but expanded after RA depending on the choice of register.
class BinaryRIEPseudo<SDPatternOperator operator, RegisterOperand cls,
Immediate imm>
: Pseudo<(outs cls:$R1), (ins cls:$R3, imm:$I2),
[(set cls:$R1, (operator cls:$R3, imm:$I2))]>;
// Like BinaryRIAndK, but expanded after RA depending on the choice of register.
multiclass BinaryRIAndKPseudo<string key, SDPatternOperator operator,
RegisterOperand cls, Immediate imm> {
let NumOpsKey = key in {
let NumOpsValue = "3" in
def K : BinaryRIEPseudo<null_frag, cls, imm>,
Requires<[FeatureHighWord, FeatureDistinctOps]>;
let NumOpsValue = "2", isConvertibleToThreeAddress = 1 in
def "" : BinaryRIPseudo<operator, cls, imm>,
Requires<[FeatureHighWord]>;
}
}
[SystemZ] Extend test-under-mask support to high GR32s llvm-svn: 191773
2013-10-01 22:41:52 +08:00
// Like CompareRI, but expanded after RA depending on the choice of register.
class CompareRIPseudo<SDPatternOperator operator, RegisterOperand cls,
Immediate imm>
: Pseudo<(outs), (ins cls:$R1, imm:$I2), [(operator cls:$R1, imm:$I2)]>;
[SystemZ] Add comparisons of high words and memory llvm-svn: 191777
2013-10-01 23:00:44 +08:00
// Like CompareRXY, but expanded after RA depending on the choice of register.
class CompareRXYPseudo<SDPatternOperator operator, RegisterOperand cls,
SDPatternOperator load, bits<5> bytes,
AddressingMode mode = bdxaddr20only>
: Pseudo<(outs), (ins cls:$R1, mode:$XBD2),
[(operator cls:$R1, (load mode:$XBD2))]> {
let mayLoad = 1;
let Has20BitOffset = 1;
let HasIndex = 1;
let AccessBytes = bytes;
}
// Like StoreRXY, but expanded after RA depending on the choice of register.
[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. llvm-svn: 191739
2013-10-01 19:26:28 +08:00
class StoreRXYPseudo<SDPatternOperator operator, RegisterOperand cls,
bits<5> bytes, AddressingMode mode = bdxaddr20only>
: Pseudo<(outs), (ins cls:$R1, mode:$XBD2),
[(operator cls:$R1, mode:$XBD2)]> {
let mayStore = 1;
let Has20BitOffset = 1;
let HasIndex = 1;
let AccessBytes = bytes;
}
[SystemZ] Allow integer AND involving high words llvm-svn: 191762
2013-10-01 22:20:41 +08:00
// Like RotateSelectRIEf, but expanded after RA depending on the choice
// of registers.
class RotateSelectRIEfPseudo<RegisterOperand cls1, RegisterOperand cls2>
: Pseudo<(outs cls1:$R1),
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
(ins cls1:$R1src, cls2:$R2, imm32zx8:$I3, imm32zx8:$I4,
imm32zx6:$I5),
[SystemZ] Allow integer AND involving high words llvm-svn: 191762
2013-10-01 22:20:41 +08:00
[]> {
let Constraints = "$R1 = $R1src";
let DisableEncoding = "$R1src";
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
// Implements "$dst = $cc & (8 >> CC) ? $src1 : $src2", where CC is
// the value of the PSW's 2-bit condition code field.
class SelectWrapper<RegisterOperand cls>
[SystemZ] Be more careful about inverting CC masks 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
2013-07-31 20:30:20 +08:00
: Pseudo<(outs cls:$dst),
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
(ins cls:$src1, cls:$src2, imm32zx4:$valid, imm32zx4:$cc),
[SystemZ] Be more careful about inverting CC masks 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
2013-07-31 20:30:20 +08:00
[(set cls:$dst, (z_select_ccmask cls:$src1, cls:$src2,
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
imm32zx4:$valid, imm32zx4:$cc))]> {
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let usesCustomInserter = 1;
// Although the instructions used by these nodes do not in themselves
[SystemZ] Rename PSW to CC Addresses a review comment from Ulrich Weigand. No functional change intended. I'm not sure whether the old TODO that this patch touches still holds, but that's something we'd get to when adding a targetted scheduling description. llvm-svn: 182474
2013-05-22 21:38:45 +08:00
// change CC, the insertion requires new blocks, and CC cannot be live
// across them.
let Defs = [CC];
let Uses = [CC];
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
}
[SystemZ] Add conditional store patterns Add pseudo conditional store instructions, so that we use: branch foo: store foo: instead of: load branch foo: move foo: store z196 has real 32-bit and 64-bit conditional stores, but we don't use any z196 instructions yet. llvm-svn: 185065
2013-06-27 17:27:40 +08:00
// Stores $new to $addr if $cc is true ("" case) or false (Inv case).
multiclass CondStores<RegisterOperand cls, SDPatternOperator store,
SDPatternOperator load, AddressingMode mode> {
let Defs = [CC], Uses = [CC], usesCustomInserter = 1 in {
[SystemZ] Be more careful about inverting CC masks 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
2013-07-31 20:30:20 +08:00
def "" : Pseudo<(outs),
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
(ins cls:$new, mode:$addr, imm32zx4:$valid, imm32zx4:$cc),
[SystemZ] Add conditional store patterns Add pseudo conditional store instructions, so that we use: branch foo: store foo: instead of: load branch foo: move foo: store z196 has real 32-bit and 64-bit conditional stores, but we don't use any z196 instructions yet. llvm-svn: 185065
2013-06-27 17:27:40 +08:00
[(store (z_select_ccmask cls:$new, (load mode:$addr),
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
imm32zx4:$valid, imm32zx4:$cc),
[SystemZ] Be more careful about inverting CC masks 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
2013-07-31 20:30:20 +08:00
mode:$addr)]>;
def Inv : Pseudo<(outs),
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
(ins cls:$new, mode:$addr, imm32zx4:$valid, imm32zx4:$cc),
[SystemZ] Add conditional store patterns Add pseudo conditional store instructions, so that we use: branch foo: store foo: instead of: load branch foo: move foo: store z196 has real 32-bit and 64-bit conditional stores, but we don't use any z196 instructions yet. llvm-svn: 185065
2013-06-27 17:27:40 +08:00
[(store (z_select_ccmask (load mode:$addr), cls:$new,
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
imm32zx4:$valid, imm32zx4:$cc),
[SystemZ] Be more careful about inverting CC masks 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
2013-07-31 20:30:20 +08:00
mode:$addr)]>;
[SystemZ] Add conditional store patterns Add pseudo conditional store instructions, so that we use: branch foo: store foo: instead of: load branch foo: move foo: store z196 has real 32-bit and 64-bit conditional stores, but we don't use any z196 instructions yet. llvm-svn: 185065
2013-06-27 17:27:40 +08:00
}
}
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
// OPERATOR is ATOMIC_SWAP or an ATOMIC_LOAD_* operation. PAT and OPERAND
// describe the second (non-memory) operand.
class AtomicLoadBinary<SDPatternOperator operator, RegisterOperand cls,
dag pat, DAGOperand operand>
: Pseudo<(outs cls:$dst), (ins bdaddr20only:$ptr, operand:$src2),
[(set cls:$dst, (operator bdaddr20only:$ptr, pat))]> {
[SystemZ] Rename PSW to CC Addresses a review comment from Ulrich Weigand. No functional change intended. I'm not sure whether the old TODO that this patch touches still holds, but that's something we'd get to when adding a targetted scheduling description. llvm-svn: 182474
2013-05-22 21:38:45 +08:00
let Defs = [CC];
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Has20BitOffset = 1;
let mayLoad = 1;
let mayStore = 1;
let usesCustomInserter = 1;
}
// Specializations of AtomicLoadWBinary.
class AtomicLoadBinaryReg32<SDPatternOperator operator>
: AtomicLoadBinary<operator, GR32, (i32 GR32:$src2), GR32>;
class AtomicLoadBinaryImm32<SDPatternOperator operator, Immediate imm>
: AtomicLoadBinary<operator, GR32, (i32 imm:$src2), imm>;
class AtomicLoadBinaryReg64<SDPatternOperator operator>
: AtomicLoadBinary<operator, GR64, (i64 GR64:$src2), GR64>;
class AtomicLoadBinaryImm64<SDPatternOperator operator, Immediate imm>
: AtomicLoadBinary<operator, GR64, (i64 imm:$src2), imm>;
// OPERATOR is ATOMIC_SWAPW or an ATOMIC_LOADW_* operation. PAT and OPERAND
// describe the second (non-memory) operand.
class AtomicLoadWBinary<SDPatternOperator operator, dag pat,
DAGOperand operand>
: Pseudo<(outs GR32:$dst),
(ins bdaddr20only:$ptr, operand:$src2, ADDR32:$bitshift,
ADDR32:$negbitshift, uimm32:$bitsize),
[(set GR32:$dst, (operator bdaddr20only:$ptr, pat, ADDR32:$bitshift,
ADDR32:$negbitshift, uimm32:$bitsize))]> {
[SystemZ] Rename PSW to CC Addresses a review comment from Ulrich Weigand. No functional change intended. I'm not sure whether the old TODO that this patch touches still holds, but that's something we'd get to when adding a targetted scheduling description. llvm-svn: 182474
2013-05-22 21:38:45 +08:00
let Defs = [CC];
[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. llvm-svn: 181203
2013-05-07 00:15:19 +08:00
let Has20BitOffset = 1;
let mayLoad = 1;
let mayStore = 1;
let usesCustomInserter = 1;
}
// Specializations of AtomicLoadWBinary.
class AtomicLoadWBinaryReg<SDPatternOperator operator>
: AtomicLoadWBinary<operator, (i32 GR32:$src2), GR32>;
class AtomicLoadWBinaryImm<SDPatternOperator operator, Immediate imm>
: AtomicLoadWBinary<operator, (i32 imm:$src2), imm>;
[SystemZ] Add a definition of the CLC instruction llvm-svn: 188162
2013-08-12 18:17:33 +08:00
[SystemZ] Extend memcpy and memset support to all constant lengths Lengths up to a certain threshold (currently 6 * 256) use a series of MVCs. Lengths above that threshold use a loop to handle X*256 bytes followed by a single MVC to handle the excess (if any). This loop will also be needed in future when support for variable lengths is added. Because the same tablegen classes are used to define MVC and CLC, the patch also has the side-effect of defining a pseudo loop instruction for CLC. That instruction isn't used yet (and wouldn't be handled correctly if it were). I'm planning to use it soon though. llvm-svn: 189331
2013-08-27 17:54:29 +08:00
// Define an instruction that operates on two fixed-length blocks of memory,
// and associated pseudo instructions for operating on blocks of any size.
// The Sequence form uses a straight-line sequence of instructions and
// the Loop form uses a loop of length-256 instructions followed by
// another instruction to handle the excess.
[SystemZ] Add a definition of the CLC instruction llvm-svn: 188162
2013-08-12 18:17:33 +08:00
multiclass MemorySS<string mnemonic, bits<8> opcode,
[SystemZ] Extend memcpy and memset support to all constant lengths Lengths up to a certain threshold (currently 6 * 256) use a series of MVCs. Lengths above that threshold use a loop to handle X*256 bytes followed by a single MVC to handle the excess (if any). This loop will also be needed in future when support for variable lengths is added. Because the same tablegen classes are used to define MVC and CLC, the patch also has the side-effect of defining a pseudo loop instruction for CLC. That instruction isn't used yet (and wouldn't be handled correctly if it were). I'm planning to use it soon though. llvm-svn: 189331
2013-08-27 17:54:29 +08:00
SDPatternOperator sequence, SDPatternOperator loop> {
[SystemZ] Add a definition of the CLC instruction llvm-svn: 188162
2013-08-12 18:17:33 +08:00
def "" : InstSS<opcode, (outs), (ins bdladdr12onlylen8:$BDL1,
bdaddr12only:$BD2),
mnemonic##"\t$BDL1, $BD2", []>;
[SystemZ] Extend memcpy and memset support to all constant lengths Lengths up to a certain threshold (currently 6 * 256) use a series of MVCs. Lengths above that threshold use a loop to handle X*256 bytes followed by a single MVC to handle the excess (if any). This loop will also be needed in future when support for variable lengths is added. Because the same tablegen classes are used to define MVC and CLC, the patch also has the side-effect of defining a pseudo loop instruction for CLC. That instruction isn't used yet (and wouldn't be handled correctly if it were). I'm planning to use it soon though. llvm-svn: 189331
2013-08-27 17:54:29 +08:00
let usesCustomInserter = 1 in {
def Sequence : Pseudo<(outs), (ins bdaddr12only:$dest, bdaddr12only:$src,
imm64:$length),
[(sequence bdaddr12only:$dest, bdaddr12only:$src,
imm64:$length)]>;
def Loop : Pseudo<(outs), (ins bdaddr12only:$dest, bdaddr12only:$src,
imm64:$length, GR64:$count256),
[(loop bdaddr12only:$dest, bdaddr12only:$src,
imm64:$length, GR64:$count256)]>;
}
[SystemZ] Add a definition of the CLC instruction llvm-svn: 188162
2013-08-12 18:17:33 +08:00
}
[SystemZ] Use CLST to implement strcmp llvm-svn: 188544
2013-08-16 19:21:54 +08:00
// Define an instruction that operates on two strings, both terminated
// by the character in R0. The instruction processes a CPU-determinated
// number of bytes at a time and sets CC to 3 if the instruction needs
// to be repeated. Also define a pseudo instruction that represents
// the full loop (the main instruction plus the branch on CC==3).
multiclass StringRRE<string mnemonic, bits<16> opcode,
SDPatternOperator operator> {
def "" : InstRRE<opcode, (outs GR64:$R1, GR64:$R2),
(ins GR64:$R1src, GR64:$R2src),
mnemonic#"\t$R1, $R2", []> {
[SystemZ] Make the CCRegs regclass non-allocatable. This was discovered to be necessary while running memchr-01.ll with -verify-machinstrs, because it is not allowed to have a phys reg live accross block boundaries while on SSA form, if the register is allocatable (expect in entry block and landing pads). In this test case, stringRRE pseudos are expanded after isel by adding a loop block which produces a live out CC register. To make the test pass, it was also necessary to not say that StringRRELoop pseudo uses R0L, this is only true for the StringRRE opcode. -verify-machineinstrs added to memchr-01.ll test. New test case int-cmp-51.ll to test that MachineCSE can eliminate an identical compare (which it couldn't do before). Reviewed by Ulrich Weigand llvm-svn: 251634
2015-10-30 00:13:55 +08:00
let Uses = [R0L];
[SystemZ] Use CLST to implement strcmp llvm-svn: 188544
2013-08-16 19:21:54 +08:00
let Constraints = "$R1 = $R1src, $R2 = $R2src";
let DisableEncoding = "$R1src, $R2src";
}
let usesCustomInserter = 1 in
def Loop : Pseudo<(outs GR64:$end),
(ins GR64:$start1, GR64:$start2, GR32:$char),
[(set GR64:$end, (operator GR64:$start1, GR64:$start2,
GR32:$char))]>;
}
[SystemZ] Define the return instruction as a pseudo alias of BR This is the first of a few patches to reduce the dupliation of encoding information. The return instruction is a normal BR in which one of the registers is fixed. llvm-svn: 191364
2013-09-25 18:20:08 +08:00
// A pseudo instruction that is a direct alias of a real instruction.
// These aliases are used in cases where a particular register operand is
// fixed or where the same instruction is used with different register sizes.
// The size parameter is the size in bytes of the associated real instruction.
class Alias<int size, dag outs, dag ins, list<dag> pattern>
: InstSystemZ<size, outs, ins, "", pattern> {
let isPseudo = 1;
let isCodeGenOnly = 1;
}
[SystemZ] Define the GR64 low-word logic instructions as pseudo aliases. 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
2013-09-25 19:11:53 +08:00
[SystemZ] Add CodeGen support for v4f32 The architecture doesn't really have any native v4f32 operations except v4f32->v2f64 and v2f64->v4f32 conversions, with only half of the v4f32 elements being used. Even so, using vector registers for <4 x float> and scalarising individual operations is much better than generating completely scalar code, since there's much less register pressure. It's also more efficient to do v4f32 comparisons by extending to 2 v2f64s, comparing those, then packing the result. This particularly helps with llvmpipe. Based on a patch by Richard Sandiford. llvm-svn: 236523
2015-05-06 03:27:45 +08:00
class UnaryAliasVRS<RegisterOperand cls1, RegisterOperand cls2>
: Alias<6, (outs cls1:$src1), (ins cls2:$src2), []>;
[SystemZ] Add CodeGen support for scalar f64 ops in vector registers 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
2015-05-06 03:28:34 +08:00
// An alias of a UnaryVRR*, but with different register sizes.
class UnaryAliasVRR<SDPatternOperator operator, TypedReg tr1, TypedReg tr2>
: Alias<6, (outs tr1.op:$V1), (ins tr2.op:$V2),
[(set tr1.op:$V1, (tr1.vt (operator (tr2.vt tr2.op:$V2))))]>;
// An alias of a UnaryVRX, but with different register sizes.
class UnaryAliasVRX<SDPatternOperator operator, TypedReg tr,
AddressingMode mode = bdxaddr12only>
: Alias<6, (outs tr.op:$V1), (ins mode:$XBD2),
[(set tr.op:$V1, (tr.vt (operator mode:$XBD2)))]>;
// An alias of a StoreVRX, but with different register sizes.
class StoreAliasVRX<SDPatternOperator operator, TypedReg tr,
AddressingMode mode = bdxaddr12only>
: Alias<6, (outs), (ins tr.op:$V1, mode:$XBD2),
[(operator (tr.vt tr.op:$V1), mode:$XBD2)]>;
[SystemZ] Define the GR64 low-word logic instructions as pseudo aliases. 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
2013-09-25 19:11:53 +08:00
// An alias of a BinaryRI, but with different register sizes.
class BinaryAliasRI<SDPatternOperator operator, RegisterOperand cls,
Immediate imm>
: Alias<4, (outs cls:$R1), (ins cls:$R1src, imm:$I2),
[(set cls:$R1, (operator cls:$R1src, imm:$I2))]> {
let Constraints = "$R1 = $R1src";
}
// An alias of a BinaryRIL, but with different register sizes.
class BinaryAliasRIL<SDPatternOperator operator, RegisterOperand cls,
Immediate imm>
: Alias<6, (outs cls:$R1), (ins cls:$R1src, imm:$I2),
[(set cls:$R1, (operator cls:$R1src, imm:$I2))]> {
let Constraints = "$R1 = $R1src";
}
[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. llvm-svn: 191739
2013-10-01 19:26:28 +08:00
[SystemZ] Add CodeGen support for integer vector types 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
2015-05-06 03:25:42 +08:00
// An alias of a BinaryVRRf, but with different register sizes.
class BinaryAliasVRRf<RegisterOperand cls>
: Alias<6, (outs VR128:$V1), (ins cls:$R2, cls:$R3), []>;
[SystemZ] Fix TMHH and TMHL usage for z10 with -O0 I've no idea why I decided to handle TMxx differently from all the other high/low logic operations, but it was a stupid thing to do. The high registers aren't available as separate 32-bit registers on z10, so subreg_h32 can't be used on a GR64 there. I've normally been testing with z196 and with -O3 and so hadn't noticed this until now. llvm-svn: 195473
2013-11-23 01:28:28 +08:00
// An alias of a CompareRI, but with different register sizes.
class CompareAliasRI<SDPatternOperator operator, RegisterOperand cls,
Immediate imm>
: Alias<4, (outs), (ins cls:$R1, imm:$I2), [(operator cls:$R1, imm:$I2)]> {
let isCompare = 1;
}
[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. llvm-svn: 191739
2013-10-01 19:26:28 +08:00
// An alias of a RotateSelectRIEf, but with different register sizes.
class RotateSelectAliasRIEf<RegisterOperand cls1, RegisterOperand cls2>
: Alias<6, (outs cls1:$R1),
[SystemZ] Avoid using i8 constants for immediate fields Immediate fields that have no natural MVT type tended to use i8 if the field was small enough. This was a bit confusing since i8 isn't a legal type for the target. Fields for short immediates in a 32-bit or 64-bit operation use i32 or i64 instead, so it would be better to do the same for all fields. No behavioral change intended. llvm-svn: 212702
2014-07-10 18:52:51 +08:00
(ins cls1:$R1src, cls2:$R2, imm32zx8:$I3, imm32zx8:$I4,
imm32zx6:$I5), []> {
[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. llvm-svn: 191739
2013-10-01 19:26:28 +08:00
let Constraints = "$R1 = $R1src";
}