The constraints are represented by the register class of the original
virtual register created for the inline asm. If the register class were
included in the operand descriptor, we might be able to do this.

For now, just give up on regclass inflation when inline asm is involved.

No test case, this bug hasn't happened yet.

llvm-svn: 134226

type/expression/template argument/etc. is instantiation-dependent if
it somehow involves a template parameter, even if it doesn't meet the
requirements for the more common kinds of dependence (dependent type,
type-dependent expression, value-dependent expression).

When we see an instantiation-dependent type, we know we always need to
perform substitution into that instantiation-dependent type. This
keeps us from short-circuiting evaluation in places where we
shouldn't, and lets us properly implement C++0x [temp.type]p2.

In theory, this would also allow us to properly mangle
instantiation-dependent-but-not-dependent decltype types per the
Itanium C++ ABI, but we aren't quite there because we still mangle
based on the canonical type in cases like, e.g.,

  template<unsigned> struct A { };
  template<typename T>
    void f(A<sizeof(sizeof(decltype(T() + T())))>) { }
  template void f<int>(A<sizeof(sizeof(int))>);

and therefore get the wrong answer.

llvm-svn: 134225

llvm-svn: 134224

llvm-svn: 134223

supporting the instruction that the constraint is for 'movw'.

Part of rdar://9119939

llvm-svn: 134222

llvm-svn: 134221

for the 'x' register constraint.

Part of rdar://9119939

llvm-svn: 134220

llvm-svn: 134219

Part of rdar://9119939

llvm-svn: 134217

llvm-svn: 134216

Part of rdar://9307836 and rdar://9119939

llvm-svn: 134215

that serve as the base template name of an unresolved-name to
be mangled as a substitution.

llvm-svn: 134213

llvm-svn: 134212

llvm-svn: 134211

llvm-svn: 134210

llvm-svn: 134209

llvm-svn: 134208

We would put the return value from long double functions in the wrong
register.

This fixes gcc.c-torture/execute/conversion.c

llvm-svn: 134205

Merge the tMOVr, tMOVgpr2tgpr, tMOVtgpr2gpr, and tMOVgpr2gpr instructions
into tMOVr. There's no need to keep them separate. Giving the tMOVr
instruction the proper GPR register class for its operands is sufficient
to give the register allocator enough information to do the right thing
directly.

llvm-svn: 134204

Part of rdar://9119939

llvm-svn: 134203

encoding for the registers it knows about. Return -1 if it can't handle that
register.

llvm-svn: 134202

llvm-svn: 134201

llvm-svn: 134200

A = X
B = X

Instead, proceed as if we had found

A = X
B = A

llvm-svn: 134199

No functional change.

Part of rdar://9119939

llvm-svn: 134198

Fix a FIXME and allow predication (in Thumb2) for the T1 register to
register MOV instructions. This allows some better codegen with
if-conversion (as seen in the test updates), plus it lays the groundwork
for pseudo-izing the tMOVCC instructions.

llvm-svn: 134197

llvm-svn: 134196

llvm-svn: 134195

llvm-svn: 134194

llvm-svn: 134193

llvm-svn: 134192

llvm-svn: 134191

llvm-svn: 134190

llvm-svn: 134189

Only prevectorize loops that are actually parallel and can
be vectorized. Take the innermost loop that is eligible.

llvm-svn: 134187

We just strip-mine the innermost dimension by the vector width. This does not
take into account if this dimension is parallel nor if it is constant.

llvm-svn: 134186

This fixes PR10223.

llvm-svn: 134183

nodes.

Original message:
Let simplify cfg simplify bb with only debug and lifetime intrinsics.

llvm-svn: 134182

isl introduced a new representation for the schedules it calculates. The new
representation uses a forest of bands and is closer to the structure of the
data as the old interface. Switch to the new interface, as it is nicer to use
and as the old interface will soon be removed from isl.

WARNING: This commit needs a version of isl that is more recent that the one
         included in CLooG. See:
	 http://polly.grosser.es/get_started.html#islTrunk
llvm-svn: 134181

Build Polly without run time type info (rtti), as otherwise Polly cannot be
loaded into a LLVM that is built without rtti.

llvm-svn: 134180