llvm-svn: 62288

Validate dbg_* intrinsics before lowering them.

llvm-svn: 62286

llvm-svn: 62285

to support MachineInstr-based scheduling in addition to
SDNode-based scheduling.

llvm-svn: 62284

loops, hoisting instructions all the way out in one step rather
than hoisting them one nest level at a time. Also, make a few
other code simplifications. This speeds up MachineLICM
by several fold.

llvm-svn: 62283

llvm-svn: 62282

llvm-svn: 62281

llvm-svn: 62279

llvm-svn: 62276

and into the ScheduleDAGInstrs class, so that they don't get
destructed and re-constructed for each block. This fixes a
compile-time hot spot in the post-pass scheduler.

To help facilitate this, tidy and do some minor reorganization
in the scheduler constructor functions.

llvm-svn: 62275

llvm-svn: 62272

this fixes PR3332

llvm-svn: 62271

Use light weight DebugInfo object directly.

llvm-svn: 62269

llvm-svn: 62267

previous commit.

llvm-svn: 62266

llvm-svn: 62265

llvm-svn: 62264

- Looking at the number of sign bits of the a sext instruction to determine  whether new trunc + sext pair should be added when its source is being evaluated in a different type.

llvm-svn: 62263

llvm-svn: 62262

llvm-svn: 62260

llvm-svn: 62259

the ADDRspii addressing mode.

llvm-svn: 62258

changes in the last commit.

llvm-svn: 62257

llvm-svn: 62256

  sequences in SPUDAGToDAGISel.cpp and SPU64InstrInfo.td, killing custom
  DAG node types as needed.
- i64 mul is now a legal instruction, but emits an instruction sequence
  that stretches tblgen and the imagination, as well as violating laws of
  several small countries and most southern US states (just kidding, but
  looking at a function with 80+ parameters is really weird and just plain
  wrong.)
- Update tests as needed.

llvm-svn: 62254

llvm-svn: 62251

llvm-svn: 62249

llvm-svn: 62244

llvm-svn: 62243

frame index. eliminateFrameIndex will replace these instructions with
(LDWSP|STWSP|LDAWSP) or (LDW|STW|LDAWF) if a frame pointer is in use.

This fixes PR 3324. Previously we used LDWSP, STWSP, LDAWSP before frame
pointer elimination. However since they were marked as implicitly using
SP they could not be rematerialised.

llvm-svn: 62238

llvm-svn: 62236

llvm-svn: 62232

my earlier patch to this file.

The issue there was that all uses of an IV inside a loop
are actually references to Base[IV*2], and there was one
use outside that was the same but LSR didn't see the base
or the scaling because it didn't recurse into uses outside
the loop; thus, it used base+IV*scale mode inside the loop
instead of pulling base out of the loop.  This was extra bad
because register pressure later forced both base and IV into
memory.  Doing that recursion, at least enough
to figure out addressing modes, is a good idea in general;
the change in AddUsersIfInteresting does this.  However,
there were side effects....

It is also possible for recursing outside the loop to
introduce another IV where there was only 1 before (if
the refs inside are not scaled and the ref outside is).
I don't think this is a common case, but it's in the testsuite.
It is right to be very aggressive about getting rid of
such introduced IVs (CheckForIVReuse and the handling of
nonzero RewriteFactor in StrengthReduceStridedIVUsers).
In the testcase in question the new IV produced this way
has both a nonconstant stride and a nonzero base, neither
of which was handled before.  And when inserting 
new code that feeds into a PHI, it's right to put such 
code at the original location rather than in the PHI's 
immediate predecessor(s) when the original location is outside 
the loop (a case that couldn't happen before)
(RewriteInstructionToUseNewBase); better to avoid making
multiple copies of it in this case.

Also, the mechanism for keeping SCEV's corresponding to GEP's
no longer works, as the GEP might change after its SCEV
is remembered, invalidating the SCEV, and we might get a bad
SCEV value when looking up the GEP again for a later loop.  
This also couldn't happen before, as we weren't recursing
into GEP's outside the loop.

Also, when we build an expression that involves a (possibly
non-affine) IV from a different loop as well as an IV from
the one we're interested in (containsAddRecFromDifferentLoop),
don't recurse into that.  We can't do much with it and will
get in trouble if we try to create new non-affine IVs or something.

More testcases are coming.

llvm-svn: 62212

Both 'llvmc -o file' and 'llvmc -ofile' should work.

llvm-svn: 62211

llvm-svn: 62209

Add member template MallocAllocator::Allocate(Num) (to match the same function in BumpPtrAllocator).

llvm-svn: 62202

vector and extraneous loop over it, 2) not delete globals used by
phis/selects etc which could actually be useful.  This fixes PR3321.
Many thanks to Duncan for narrowing this down.

llvm-svn: 62201

Removoe MachineModuleInfo methods (and related DebugInfoDesc class  hierarchy) that were used to handle debug info.

llvm-svn: 62199

llvm-svn: 62198

llvm-svn: 62196