llvm-svn: 104265

llvm-svn: 104264

llvm-svn: 104263

operand on the left, the interesting operand is on the right. This
fixes a bug where LSR was failing to recognize ICmpZero uses,
which led it to be unable to reverse the induction variable in the
attached testcase.

Delete test/CodeGen/X86/stack-color-with-reg-2.ll, because its test
is extremely fragile and hard to meaningfully update.

llvm-svn: 104262

llvm-svn: 104261

it isn't a very interesting change, it's a change nonetheless.

llvm-svn: 104260

This fixes the remaining issue with pr7167.

llvm-svn: 104257

llvm-svn: 104254

llvm-svn: 104253

Also, fix output defaulting to match llvm-mc.

llvm-svn: 104246

have a pattern and it had an invalid encoding.

llvm-svn: 104244

Driver/MC: Add 'clang -cc1as' integrated assembler tool, currently accepts approximately the same interface as 'llvm-mc'.

llvm-svn: 104239

registers.  Currently it is not so marked, which leads to
VCMPEQ instructions that feed into it getting deleted.
If it is so marked, local RA complains about this sequence:
 vreg = MCRF  CR0
 MFCR  <kill of whatever preg got assigned to vreg>
All current uses of this instruction are only interested in
one of the 8 CR registers, so redefine MFCR to be a normal
unary instruction with a CR input (which is emitted only as
a comment).  That avoids all problems.  7739628.

llvm-svn: 104238

llvm-svn: 104237

llvm-svn: 104236

be turned into a setter call (fixes radar 8008649).

llvm-svn: 104235

llvm-svn: 104234

Split DbgVariable. Eventually, variable info will be communicated through frame index, or DBG_VALUE instruction, or collection of DBG_VALUE instructions. Plus each DbgVariable may not need a label.

llvm-svn: 104233

llvm-svn: 104232

instructions.

llvm-svn: 104231

llvm-svn: 104230

llvm-svn: 104229

16-bit and 32-bit pushf and popf.

llvm-svn: 104228

particular issue was the cause of the Boost.Interprocess failures, and
in general will lead to horrendous, hard-to-diagnose miscompiles. The
assertion itself has survives self-host and a full Boost build, so we
are close to eradicating this problem in C++.

Note that the assertion is *not* turned on for Objective-C++, where we
still have problems with introducing memcpy's of non-POD class
types. That part of the assertion will go away as soon as we fix the
known issues in Objective-C++.

llvm-svn: 104227

llvm-svn: 104226

and fix a bug that valgrind noticed where the code would std::swap an
element with itself.

llvm-svn: 104225

llvm-svn: 104224

llvm-svn: 104223

Fix my inability to spell 'continue' and a case where message sends returning non-pointer-sized things were generating invalid IR inside @try blocks.

llvm-svn: 104222

Renamed misleading getSourceRange -> getLocalSourceRange and getFullSourceRange -> getSourceRange for TypeLoc.

llvm-svn: 104220

subobject. Previously, we could only properly bind to a base class
subobject while extending the lifetime of the complete object (of a
derived type); for non-static data member subobjects, we could memcpy
(!) the result and bind to that, which is rather broken.

Now, we pull apart the expression that we're binding to, to figure out
which subobject we're accessing, then construct the temporary object
(adding a destruction if needed) and, finally, dig out the subobject
we actually meant to access.

This fixes yet another instance where we were memcpy'ing rather than
doing the right thing. However, note the FIXME in references.cpp:
there's more work to be done for binding to subobjects, since the AST
is incorrectly modeling some member accesses in base classes as
lvalues when they are really rvalues.

llvm-svn: 104219

llvm-svn: 104218

<rdar://problem/7995494>.

llvm-svn: 104217

pipeline stall. It's useful for targets like ARM cortex-a8. NEON has a lot
of long latency instructions so a strict register pressure reduction
scheduler does not work well.
Early experiments show this speeds up some NEON loops by over 30%.

llvm-svn: 104216

class type (that uses a return slot), pass the return slot to the
callee directly rather than allocating new storage and trying to copy
the object. This appears to have been the cause of the remaining two
Boost.Interprocess failures.

llvm-svn: 104215

llvm-svn: 104209

llvm-svn: 104208

llvm-svn: 104207

instance variables:
  - Use isRecordType() rather than isa<RecordType>(), so that we see
  through typedefs in ivar types.
  - Mark the destructor as referenced
  - Perform C++ access control on the destructor

llvm-svn: 104206

llvm-svn: 104205