input and output types when the smaller value isn't mentioned in the
asm string.  Extend this support from integers to also allowing 
fp values to be mismatched (if not mentioned in the asm string).

llvm-svn: 102188

llvm-svn: 102187

Require a complete type for the lhs of member pointer dereference operations if the type isn't exactly the same as the container class. Fixes PR6783.

llvm-svn: 102186

llvm-svn: 102183

llvm-svn: 102182

variants.  This fixes neon inline asm which my patch for PR6780 broke.

llvm-svn: 102181

declaration that this typedef gives the tag a name. Fixes a problem
uncovered by Boost.GIL (Generic Image Library).

llvm-svn: 102180

llvm-svn: 102179

llvm-svn: 102178

patch by mikem!

llvm-svn: 102177

itself too.

llvm-svn: 102176

llvm-svn: 102175

Revert "C++ doesn't really use "namespaces" for different kinds of names the same", which seems to break most C++ nightly test apps.

llvm-svn: 102174

llvm-svn: 102172

names.

llvm-svn: 102171

permitted in C++ but not in C. Fixes PR6900. Clang can now handle all
of Boost.Lambda's regression tests.

llvm-svn: 102170

llvm-svn: 102169

llvm-svn: 102168

  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