Now there is no special treatment of instructions that redefine part of a
super-register. Instead, the super-register is marked with <imp-use,kill> and
<imp-def>. For instance, from LowerSubregs on ARM:

subreg: CONVERTING: %Q1<def> = INSERT_SUBREG %Q1<undef>, %D1<kill>, 5
subreg: %D2<def> = FCPYD %D1<kill>, 14, %reg0, %Q1<imp-def>

subreg: CONVERTING: %Q1<def> = INSERT_SUBREG %Q1, %D0<kill>, 6
subreg: %D3<def> = FCPYD %D0<kill>, 14, %reg0, %Q1<imp-use,kill>, %Q1<imp-def>
llvm-svn: 78466

Verify that early clobber registers and their aliases are not used.

All changes to RegsAvailable are now done as a transaction so the order of
operands makes no difference.

The included test case is from PR4686. It has behaviour that was dependent on the order of operands.

llvm-svn: 78465

llvm-svn: 78464

 - This doesn't actually improve the algorithm (its still linear), but the
   generated (match) code is now fairly compact and table driven. Still need a
   generic string matcher.

 - The table still needs to be compressed, this is quite simple to do and should
   shrink it to under 16k.

 - This also simplifies and restructures the code to make the match classes more
   explicit, in anticipation of resolving ambiguities.

llvm-svn: 78461

so I generalized the class for VTRN in the .td file to handle all 3 of them.

llvm-svn: 78460

directly from the intrinsics produced by the frontend.  If it is more
convenient to have a custom DAG node for using these to implement shuffles,
we can add that later.

llvm-svn: 78459

llvm-svn: 78456

llvm-svn: 78455

llvm-svn: 78454

llvm-svn: 78453

error condition get trapped with an assert.

llvm-svn: 78449

llvm-svn: 78447

llvm-svn: 78444

llvm-svn: 78443

llvm-svn: 78432

llvm-svn: 78430

llvm-svn: 78428

llvm-svn: 78426

llvm-svn: 78425

llvm-svn: 78421

llvm-svn: 78420

llvm-svn: 78419

llvm-svn: 78418

llvm-svn: 78416

llvm-svn: 78411

llvm-svn: 78410

llvm-svn: 78405

llvm-svn: 78404

http://llvm.org/viewvc/llvm-project?view=rev&revision=78127, I'm changing the
ExecutionEngine's global mappings to hold AssertingVH<const GlobalValue>. That
way, if unregistering a mapping fails to actually unregister it, we'll get an
assert. Running the jit nightly tests didn't uncover any actual instances of
the problem.

This also uncovered the fact that AssertingVH<const X> didn't work, so I fixed
that too.

llvm-svn: 78400

llvm-svn: 78399

llvm-svn: 78398

llvm-svn: 78397

LoopDependenceAnalysis::getLoops is currently O(N*M) for a loop-nest of
depth N and a compound SCEV of M atomic SCEVs. As both N and M will
typically be very small, this should not be a problem. If it turns out
to be one, rewriting getLoops as SCEVVisitor will reduce complexity to
O(M).

llvm-svn: 78394

preference; no functional change.

llvm-svn: 78391

Patch by Jakub Staszak.

llvm-svn: 78388

llvm-svn: 78383

llvm-svn: 78382

llvm-svn: 78381

i386-apple-darwin9. This presumably will get fixed once the generated code
improves.

llvm-svn: 78379

 - Still not very sane, but a least its not 60k lines on X86. :)

 - In terms of correctness, currently some things are hard wired for X86, and we
   still don't properly resolve ambiguities (this is ignoring the instructions
   we don't even match due to funny .td stuff or other corner cases).

The high level changes:
 1. Represent tokens which are significant for matching explicitly as separate
    operands. This uniformly handles not only the instruction mnemonic, but
    also 'signficiant' syntax like the '*' in "call * ...".

 2. Separate the matching of operands to an instruction from the construction of
    the MCInst. In theory this can be done during matching, but since the number
    of variations is small I think it makes sense to decompose the problems.

 3. Improved a few of the mechanisms to at least successfully flatten / tokenize
    the assembly strings for PowerPC and ARM.

 4. The comment at the top of AsmMatcherEmitter.cpp explains the approach I'm
    moving towards for handling ambiguous instructions. The high-bit is to infer
    a partial ordering of the operand classes (and force the user to specify one
    if we can't) and use that to resolve ambiguities.

llvm-svn: 78378