llvm-svn: 102278

llvm-svn: 102276

No visible change.

llvm-svn: 102240

the variable that we set as though it came from the user. Fixes PR6835.

llvm-svn: 102239

llvm-svn: 102237

When a load operand is promoted to an extload, replace other uses with uses of extload result truncated.

llvm-svn: 102236

that indvars may use, now that indvars is recognizing le and ge loops.

llvm-svn: 102235

Also, generalize ScalarEvolutions's min and max recognition to handle
some new forms of min and max that this change makes more common.

llvm-svn: 102234

llvm-svn: 102233

llvm-svn: 102232

refactored out of ScalarEvolution::isImpliedCond, which will be updated
to use this new utility routine soon.

llvm-svn: 102229

testcase yet, as the testcase now fails downstream.

llvm-svn: 102228

operands correctly.

llvm-svn: 102227

cross-build Makefile needs to unset CFLAGS/CXXFLAGS when building the build-side utilities since the flags will be for the cross-compiler.

llvm-svn: 102225

llvm-svn: 102220

memory operands rather than immediate operands.

llvm-svn: 102217

llvm-svn: 102216

the worklist, making them inline candidates.

llvm-svn: 102213

alignment to match what's used in clang and GCC for __alignof, rather
than trying to guess what Legalize is going to be doing.

llvm-svn: 102206

llvm-svn: 102202

llvm-svn: 102199

llvm-svn: 102197

This fixes a bug where calls inlined into an invoke would get
changed into an invoke but the array would keep pointing to
the (now dead) call.  The improved inliner behavior is still
disabled for now.

llvm-svn: 102196

llvm-svn: 102195

Add the instruction pointer value for debuggability.  
We now get dump output that looks like this:

Call graph node for function: 'f1'<<0x1017086b0>>  #uses=1
  CS<0x1017046f8> calls external node

Call graph node for function: '_ZNSt6vectorIdSaIdEEC1EmRKdRKS0_'<<0x1017086f0>>  #uses=1
  CS<0x0> calls external node

Call graph node for function: 'f4'<<0x1017087a0>>  #uses=1
  CS<0x101708c88> calls function 'f3'

llvm-svn: 102194

llvm-svn: 102192

itself too.

llvm-svn: 102176

llvm-svn: 102175

flags, to determine whether or not the operand is
a memory operand.

llvm-svn: 102158

misses an opportunity to fold add operands, but folds them
after LSR has separated them out. This fixes rdar://7886751.

llvm-svn: 102157

use ScalarEvolutions "any" extend function.

llvm-svn: 102156

because 102004 causes codegen to emit invalid assembly on at least
x86_64-unknown-gnu-linux.

llvm-svn: 102155

PR6888 with:

$ llvm-as t.ll
llvm-as: t.ll:2:29: error: expected metadata or 'align'
 store <3 x i32> %x, i32 1, i32 1>, <3 x i32>* %p
                            ^

instead of:

$ llvm-as t.ll 
llvm-as: 

llvm-svn: 102154

llvm-svn: 102153

that appear in the SCC as a result of inlining as candidates
for inlining.  Change this so that it *does* consider call 
sites that change from being indirect to being direct as a
result of inlining.  This allows it to completely 
"devirtualize" the testcase.

llvm-svn: 102146

extraction. This fixes PR5998.

llvm-svn: 102144

the definition of the nsw and nuw flags to make use of it.

nsw was introduced to help optimizers answer yes to the following:

  // Can we change i from i32 to i64 to eliminate the cast inside the loop?
  for (int i = 0; i < n; ++i) A[i] *= 0.1;

  // Can we assume that this loop will eventually terminate?
  for (int i = 0; i <= n; ++i) A[i] *= 0.1;

In its current form, it isn't truly sufficient for either.

In the first case, if the increment overflows, it'll still have some
valid i32 value; sign-extending it will produce a value which is 33
homogeneous sign bits trailed by 31 independent undef bits. If i is
promoted to i64, it won't have those same values when it reaches that
point. (The compiler could recover here by reasoning about how i is
used by the load, but that's a lot more complicated and isn't always
possible.)

In the second case, there is no value for i which will be greater than
n, so having the increment return undef on overflow doesn't help.

Trap values are a formalization of some existing concepts that we have
about LLVM IR, and give the optimizers a better basis for answering yes
to both questions above.

llvm-svn: 102140

arguments are handled with a new InlineFunctionInfo class.  This 
makes it easier to extend InlineFunction to return more info in the
future.

llvm-svn: 102137

llvm-svn: 102135

llvm-svn: 102132