it has more than one real use (non-chain uses).
* Record folded chain producing node in CodeGenMap.
* Do not fold a chain producing node if it has already been selected as an
operand of a chain use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24647 91177308-0d34-0410-b5e6-96231b3b80d8
matching code that is not currently auto-generated by tblgen, e.g. X86
addressing mode. Selection routines for complex patterns can return multiple operands, e.g. X86 addressing mode returns 4.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24634 91177308-0d34-0410-b5e6-96231b3b80d8
* Enhanced tblgen to handle instructions which have chain operand and writes a
chain result.
* Enhanced tblgen to handle instructions which produces no results. Part of
the change is a temporary hack which relies on instruction property (e.g.
isReturn, isBranch). The proper fix would be to change the .td syntax to
separate results dag from ops dag.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24587 91177308-0d34-0410-b5e6-96231b3b80d8
def SHL8rCL : I<0xD2, MRM4r, (ops R8 :$dst, R8 :$src),
"shl{b} {%cl, $dst|$dst, %CL}",
[(set R8:$dst, (shl R8:$src, CL))]>, Imp<[CL],[]>;
This generates a CopyToReg operand and added its 2nd result to the shl as
a flag operand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24557 91177308-0d34-0410-b5e6-96231b3b80d8
ValueType from the RegisterClass or Operands. This step is necessary to
allow RegisterClasses to have multiple ValueTypes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24555 91177308-0d34-0410-b5e6-96231b3b80d8
tblgen: In ZAPNOTi: Cannot use 'IZAPX' in an input pattern!
for a bad pattern, instead of an ugly assertion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23854 91177308-0d34-0410-b5e6-96231b3b80d8
1. If an operation has to be int or fp and the target only supports one
int or fp type, relize that the op has to have that type.
2. If a target has operations on multiple types, do not emit matching code
for patterns involving those operators, since we do not emit the code to
check for them yet. This prevents PPC from generating FP ops currently.
Also move some code around into more logical places.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23724 91177308-0d34-0410-b5e6-96231b3b80d8
doesn't have to specify them manually. It currently handles associativity,
e.g. knowing that (X*Y)+Z also matches X+(Y*Z) and will be extended in
the future.
It is smart enough to not introduce duplicate patterns or patterns that can
never match.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23526 91177308-0d34-0410-b5e6-96231b3b80d8
Currently we check that immediate values live on the RHS of commutative
operators. Defining ORI like this, for example:
def ORI : DForm_4<24, (ops GPRC:$dst, GPRC:$src1, u16imm:$src2),
"ori $dst, $src1, $src2",
[(set GPRC:$dst, (or immZExt16:$src2, GPRC:$src1))]>;
results in:
tblgen: In ORI: Instruction can never match: Immediate values must be on the RHS of commutative operators!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23501 91177308-0d34-0410-b5e6-96231b3b80d8
This does not check that types match yet, but PPC only has one integer type
;-).
This also doesn't have the code to build the resultant dag.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23414 91177308-0d34-0410-b5e6-96231b3b80d8
xforms. Run type inference on result patterns, so we always have fully typed
results (and to catch errors in .td files).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23369 91177308-0d34-0410-b5e6-96231b3b80d8
constraints defined in the DAG node definitions in the .td files. This
allows us to infer (and check!) the types for all nodes in the current
ppc .td file. For example, instead of:
Inst pattern EQV: (set GPRC:i32:$rT, (xor (xor GPRC:i32:$rA, GPRC:i32:$rB), (imm)<<Predicate_immAllOnes>>))
we now fully infer:
Inst pattern EQV: (set:void GPRC:i32:$rT, (xor:i32 (xor:i32 GPRC:i32:$rA, GPRC:i32:$rB), (imm:i32)<<Predicate_immAllOnes>>))
from: (set GPRC:$rT, (not (xor GPRC:$rA, GPRC:$rB)))
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23284 91177308-0d34-0410-b5e6-96231b3b80d8
progress. It correctly parses instructions and pattern fragments and glues
together pattern fragments into instructions.
The only code it generates currently is some boilerplate code for things
like the EntryNode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23261 91177308-0d34-0410-b5e6-96231b3b80d8
