active now.  Scheduling itinerary next.

llvm-svn: 23869

tblgen: In ZAPNOTi: Cannot use 'IZAPX' in an input pattern!
for a bad pattern, instead of an ugly assertion.

llvm-svn: 23854

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.
llvm-svn: 23819

llvm-svn: 23817

instead of a happy error message

llvm-svn: 23816

def : Pat<(trunc G8RC:$in),
          (OR8To4 G8RC:$in, X0)>;

Even though this doesn't make any sense on PPC :)

llvm-svn: 23815

llvm-svn: 23814

patterns.  Certainly a logical request.

llvm-svn: 23810

llvm-svn: 23780

SelectNodeTo instead of getTargetNode when possible.

llvm-svn: 23758

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.

llvm-svn: 23748

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.

llvm-svn: 23730

Overall, no functionality change yet though.

llvm-svn: 23729

llvm-svn: 23728

llvm-svn: 23725

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.

llvm-svn: 23724

llvm-svn: 23723

llvm-svn: 23584

llvm-svn: 23564

llvm-svn: 23562

trim down the target info structs now that we have a preferred spill register class for each callee save register

llvm-svn: 23560

llvm-svn: 23553

llvm-svn: 23550

llvm-svn: 23549

not defs.

Implement support for forward definitions of classes.  This implements
TableGen/ForwardRef.td.

llvm-svn: 23548

llvm-svn: 23546

used on a def.

llvm-svn: 23545

llvm-svn: 23543

llvm-svn: 23542

llvm-svn: 23540

find all of teh pattern matches for EQV from one definition

llvm-svn: 23529

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.

llvm-svn: 23526

llvm-svn: 23502

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!
llvm-svn: 23501

llvm-svn: 23499

file

llvm-svn: 23492

llvm-svn: 23488

llvm-svn: 23457

which is not stable.

llvm-svn: 23456

llvm-svn: 23454