addrec in a different loop to check the value being added to
the accumulated Start value, not the Start value before it has
the new value added to it. This prevents LSR from going crazy
on the included testcase. Dale, please review.

llvm-svn: 64440

after sorting by stride value. This prevents it from missing
IV reuse opportunities in a host-sensitive manner.

llvm-svn: 64415

loop induction on LP64 targets. When the induction variable is
used in addressing, IndVars now is usually able to inserst a
64-bit induction variable and eliminates the sign-extending cast.
This is also useful for code using C "short" types for
induction variables on targets with 32-bit addressing.

Inserting a wider induction variable is easy; the tricky part is
determining when trunc(sext(i)) expressions are no-ops. This
requires range analysis of the loop trip count. A common case is
when the original loop iteration starts at 0 and exits when the
induction variable is signed-less-than a fixed value; this case
is now handled.

This replaces IndVarSimplify's OptimizeCanonicalIVType. It was
doing the same optimization, but it was limited to loops with
constant trip counts, because it was running after the loop
rewrite, and the information about the original induction
variable is lost by that point.

Rename ScalarEvolution's executesAtLeastOnce to
isLoopGuardedByCond, generalize it to be able to test for
ICMP_NE conditions, and move it to be a public function so that
IndVars can use it.

llvm-svn: 64407

when the loop has exactly one exit, and make use of it in
LoopIndexSplit.

llvm-svn: 64388

llvm-svn: 64376

llvm-svn: 64363

forget about already inserted expressions.

llvm-svn: 64362

llvm-svn: 64352

the two non-mask arguments to a shufflevector must be the same width, but they do not have to be the same
width as the result value.

llvm-svn: 64335

llvm-svn: 64226

llvm-svn: 64207

llvm-svn: 64177

llvm-svn: 64065

llvm-svn: 64062

changes the address space of the pointer.

llvm-svn: 64035

llvm-svn: 64003

llvm-svn: 63923

llvm-svn: 63916

Ignore dbg intrinsics while propagating conditional expression info. Take 2.

llvm-svn: 63898

Revert rev. 63876. It is causing llvm-gcc bootstrap failure.

llvm-svn: 63888

llvm-svn: 63880

llvm-svn: 63876

If "optimize for size" attribute is set then block non-trivial loop unswitches but allow trivial loop unswitches.

llvm-svn: 63670

llvm-svn: 63659

renaming it to ConvertScalar_ExtractValue

llvm-svn: 63658

no functionality change.

llvm-svn: 63652

functionality change.

llvm-svn: 63651

aggregate values.  loads are not yet handled (coming
soon to an sroa near you).

llvm-svn: 63649

accessed at least once as a vector.  This prevents it from
compiling the example in not-a-vector into:

define double @test(double %A, double %B) {
	%tmp4 = insertelement <7 x double> undef, double %A, i32 0
	%tmp = insertelement <7 x double> %tmp4, double %B, i32 4
	%tmp2 = extractelement <7 x double> %tmp, i32 4
	ret double %tmp2
}

instead, producing the integer code.  Producing vectors when they
aren't otherwise in the program is dangerous because a lot of other
code treats them carefully and doesn't want to break them down.
OTOH, many things want to break down tasty i448's.

llvm-svn: 63638

llvm-svn: 63631

llvm-svn: 63620

crazy cases like:

struct f {  int A, B, C, D, E, F; };
short test4() {
  struct f A;
  A.A = 1;
  memset(&A.B, 2, 12);
  return A.C;
}

llvm-svn: 63596

With the new world order, it can handle cases where the first
store into the alloca is an element of the vector, instead of
requiring the first analyzed store to have the vector type 
itself.  This allows us to un-xfail 
test/CodeGen/X86/vec_ins_extract.ll.

llvm-svn: 63590

llvm-svn: 63544

tests.  Thanks for the beautiful reduced testcase Duncan!

llvm-svn: 63529

and remove trailing whitespace.  No functionality
change.

llvm-svn: 63511

llvm-svn: 63510

llvm-svn: 63500

turn icmp eq a+x, b+x into icmp eq a, b if a+x or b+x has other uses. This
may have been increasing register pressure leading to the bzip2 slowdown.

llvm-svn: 63487

improvements to the EvaluateInDifferentType code.  This code works 
by just inserted a bunch of new code and then seeing if it is 
useful.  Instcombine is not allowed to do this: it can only insert
new code if it is useful, and only when it is converging to a more
canonical fixed point.  Now that we iterate when DCE makes progress,
this causes an infinite loop when the code ends up not being used.

llvm-svn: 63483