llvm-svn: 134244

t2MOVCC[ri] are just t2MOV[ri] instructions, so properly pseudo-ize them.
The Thumb1 versions, tMOVCC[ri] were only present for use by the size-
reduction pass, so they're no longer necessary at all and can be deleted.

llvm-svn: 134242

llvm-svn: 134240

llvm-svn: 134238

copy is a kill") to see if it fixes the i386 dragonegg buildbot, which is timing out
because gcc built with dragonegg is going into an infinite loop.

llvm-svn: 134237

llvm-svn: 134236

llvm-svn: 134235

llvm-svn: 134234

llvm-svn: 134232

llvm-svn: 134231

I am giving up the fight...

llvm-svn: 134230

llvm-svn: 134229

llvm-svn: 134228

This is kindof questionable but seems to do more-or-less the right thing.
This is not a particularly friendly part of the ABI.

llvm-svn: 134227

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