llvm-svn: 78475

Also don't dereference old pointers after they have been deleted causing
random crashes when enabling the machine code verifier.

Ahem...

I have not included a test case for the crash. It hapened when enabling the
verifier on CodeGen/X86/2009-08-06-branchfolder-crash.ll.

The crash depends on an MBB being allocated at the same address as a
previously deleted MBB. I don't think that can be reproduced reliably.

llvm-svn: 78472

Did anyone tests v4f32 ever?

llvm-svn: 78470

llvm-svn: 78469

llvm-svn: 78468

* Cleaner handling of <undef>.
* <def> takes precedence over <def,dead>.
* Implement the OK-to-redefine-a-register-that-was-
  live-in-but-has-not-been-used-before rule.

llvm-svn: 78467

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