If store's chain operand is load, then use load's chain operand instead. If
it isn't (likely a TokenFactor), then do not allow the folding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25708 91177308-0d34-0410-b5e6-96231b3b80d8
has already been selected. The number of use check is not strong enough since
a node can be replaced with newly created target node. e.g. If the original
node has two uses, when it is selected for one of the uses it is replaced with
another. Each node now has a single use but isel still should not fold it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25651 91177308-0d34-0410-b5e6-96231b3b80d8
instruction to produce a result. e.g MUL8m, the instruction does not
produce a explicit result. However it produces an implicit result in
AL which would be copied to a temp. The root operator of the matching
pattern is a mul so the use would expect it to produce a result.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25458 91177308-0d34-0410-b5e6-96231b3b80d8
SNDPOutFlag to DAG nodes. These properties do not belong to target specific
instructions.
* Added DAG node property SNDPOptInFlag. It's same as SNDPInFlag except it's
optional. Used by ret / call, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25154 91177308-0d34-0410-b5e6-96231b3b80d8
SDOperand Tmp0,Tmp1,Tmp2,Tmp3,;
GCC has a bug (24907) in which is fails to catch this, but VC++ correctly
notes its illegality, so tblgen must be taught to only generate legal C++.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25075 91177308-0d34-0410-b5e6-96231b3b80d8
Currently tblgen cannot tell which operands in the operand list are results so
it assumes the first one is a result. This is bad. Ideally we would fix this
by separating results from inputs, e.g. (res R32:$dst),
(ops R32:$src1, R32:$src2). But that's a more distruptive change. Adding
'let noResults = 1' is the workaround to tell tblgen that the instruction does
not produces a result. It works for now since tblgen does not support
instructions which produce multiple results.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25017 91177308-0d34-0410-b5e6-96231b3b80d8
use too much stack space, overflowing the stack for large functions. Instead
of emitting new SDOperands in each match block, we emit some common ones at
the top of SelectCode then reuse them when possible.
This reduces the stack size of SelectCode from 28K to 21K. Note that GCC
compiles it to 512 bytes :-/
I've filed GCC PR 25505 to track this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24882 91177308-0d34-0410-b5e6-96231b3b80d8
if (!N.Val->hasOneUse()) {
std::map<SDOperand, SDOperand>::iterator CGMI = CodeGenMap.find(N);
if (CGMI != CodeGenMap.end()) return CGMI->second;
}
Suppose a DAG like this:
X
^ ^
/ \
USE1 USE2
Suppose USE1 is being selected first and during which X is selected and
returned a new node. After this, USE1 is no longer an use of X. During USE2
selection, X will be selected again since it has only one use!
The fix is to always query CodeGenMap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24679 91177308-0d34-0410-b5e6-96231b3b80d8
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
write things like this:
def : Pat<(add GPRC:$in, 12),
(ADD12 GPRC:$in)>;
Andrew: if this isn't enough or doesn't work for you, please lemme know.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23819 91177308-0d34-0410-b5e6-96231b3b80d8
def : Pat<(trunc G8RC:$in),
(OR8To4 G8RC:$in, X0)>;
Even though this doesn't make any sense on PPC :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23815 91177308-0d34-0410-b5e6-96231b3b80d8
a pattern match, make sure to emit the (minimal number of) type checks that
verify the pattern matches this specific instruction. This allows FMA32
patterns to not match double expressions for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23748 91177308-0d34-0410-b5e6-96231b3b80d8
type constraint. This lets tblgen realize that it doesn't need any dynamic
type checks for fextend/fround on PPC (and many other targets), because there
are only two fp types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23730 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
