Temporary solution: added a different set of BCTRL_Macho / BCTRL_ELF with right callee-saved defs set for ppc64.

llvm-svn: 43248

llvm-svn: 43247

llvm-svn: 43246

llvm-svn: 43245

llvm-svn: 43244

llvm-svn: 43243

llvm-svn: 43242

llvm-svn: 43241

llvm-svn: 43240

llvm-svn: 43239

llvm-svn: 43238

llvm-svn: 43237

llvm-svn: 43236

llvm-svn: 43235

llvm-svn: 43234

llvm-svn: 43233

llvm-svn: 43232

 - Avoid attempting stride-reuse in the case that there are users that
   aren't addresses. In that case, there will be places where the
   multiplications won't be folded away, so it's better to try to
   strength-reduce them.

 - Several SSE intrinsics have operands that strength-reduction can
   treat as addresses. The previous item makes this more visible, as
   any non-address use of an IV can inhibit stride-reuse.

 - Make ValidStride aware of whether there's likely to be a base
   register in the address computation. This prevents it from thinking
   that things like stride 9 are valid on x86 when the base register is
   already occupied.

Also, XFAIL the 2007-08-10-LEA16Use32.ll test; the new logic to avoid
stride-reuse elimintes the LEA in the loop, so the test is no longer
testing what it was intended to test.

llvm-svn: 43231

by the recent {U,S}MUL_LOHI changes.

llvm-svn: 43230

Use ptr type in the immediate field of a BxA instruction so we don't end up selecting 32-bit call instruction for ppc64.

llvm-svn: 43228

llvm-svn: 43227

llvm-svn: 43226

funky bit-widths.

llvm-svn: 43225

SCEV subclasses to being non-static member functions of the ScalarEvolution
class.

llvm-svn: 43224

operations so they work right for integers with funky
bit-widths.  For example, consider extending i48 to i64
on a 32 bit machine.  The i64 result is expanded to 2 x i32.
We know that the i48 operand will be promoted to i64, then
also expanded to 2 x i32.  If we had the expanded promoted
operand to hand, then expanding the result would be trivial.
Unfortunately at this stage we can only get hold of the
promoted operand.  So instead we kind of hand-expand, doing
explicit shifting and truncating to get the top and bottom
halves of the i64 operand into 2 x i32, which are then used
to expand the result.  This is harmless, because when the
promoted operand is finally expanded all this bit fiddling
turns into trivial operations which are eliminated either
by the expansion code itself or the DAG combiner.

llvm-svn: 43223

llvm-svn: 43222

llvm-svn: 43221

llvm-svn: 43220

llvm-svn: 43219

llvm-svn: 43218

llvm-svn: 43217

llvm-svn: 43216

llvm-svn: 43215

llvm-svn: 43214

llvm-svn: 43213

llvm-svn: 43212

- Remove a bogus assertion.

llvm-svn: 43211

llvm-svn: 43210

llvm-svn: 43209

 - enable phi instructions demotion to stack
 - create alloca instructions in the entry block

llvm-svn: 43208