T::apply <U>::type

Fixes PR6899, although I want to dig a little deeper into the FIXME
for dependent template names that refer to operators.

llvm-svn: 102167

Add an ImplicitInitializerKind enum and pass it to BuildImplicitBaseInitializer and BuildImplicitMemberInitializer.

llvm-svn: 102166

llvm-svn: 102165

way that C does.  Among other differences, elaborated type specifiers
are defined to skip "non-types", which, as you might imagine, does not
include typedefs.  Rework our use of IDNS masks to capture the semantics
of different kinds of declarations better, and remove most current lookup
filters.  Removing the last remaining filter is more complicated and will
happen in a separate patch.

Fixes PR 6885 as well some spectrum of unfiled bugs.

llvm-svn: 102164

llvm-svn: 102163

llvm-svn: 102162

try to annotate as a type first to determine whether we have a
functional-style cast. Patch by Eli Friedman, fixes PR6830.

llvm-svn: 102161

llvm-svn: 102160

Remove calls to isDependentContext, since we handle that case earlier in the code. Make BuildImplicitBaseInitializer return a boolean instead.

llvm-svn: 102159

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

llvm-svn: 102147

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

llvm-svn: 102145

extraction. This fixes PR5998.

llvm-svn: 102144

aren't and never were used. There's a gap in the bit pattern for IDNS
now, but I'm sure *someone* will fill it.

llvm-svn: 102143

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

statement, i.e., 

  for (element in collection) {
    // do something
  }

llvm-svn: 102138

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: 102134

llvm-svn: 102133

llvm-svn: 102132

define void @f3(void (i8*)* %__f) ssp {
entry:
  call void %__f(i8* undef)
  unreachable
}

define void @f4(i8* %this) ssp align 2 {
entry:
  call void @f3(void (i8*)* @f2) ssp
  ret void
}

The inliner is turning the indirect call to %__f into a direct
call to F2.  Make the call graph more precise when this happens.

The inliner doesn't revisit call sites introduced by inlining,
so there isn't an easy way to test for this, but a more precise
callgraph is a good thing.

llvm-svn: 102131

in pch.

llvm-svn: 102130

llvm-svn: 102129

into SelectionDAGBuilder itself.

llvm-svn: 102128

llvm-svn: 102127

llvm-svn: 102126

llvm-svn: 102125

llvm-svn: 102124

and into SelectionDAGBuilder and FastISel.

llvm-svn: 102123

llvm-svn: 102121

Fix RefreshCallGraph to use CGN->replaceCallEdge instead of hand
rolling its own loop.  replaceCallEdge properly maintains the
reference counts of the nodes, fixing a crash exposed by the
iterative callgraph stuff.

llvm-svn: 102120

llvm-svn: 102119

llvm-svn: 102112