MC/ARM: Add basic support for handling predication by parsing it out of the mnemonic into a separate operand form.

llvm-svn: 110794

llvm-svn: 110793

llvm-svn: 110792

llvm-mc: Add -show-inst-operands, for dumping the parsed instruction representation before matching.

llvm-svn: 110791

llvm-svn: 110790

llvm-svn: 110789

llvm-svn: 110788

llvm-svn: 110787

instructions: dmb, dsb, isb, msr, and mrs.

llvm-svn: 110786

  memory and synchronization barrier dmb and dsb instructions.
- Change instruction names to something more sensible (matching name of actual
  instructions).
- Added tests for memory barrier codegen.

llvm-svn: 110785

llvm-svn: 110784

llvm-svn: 110783

llvm-svn: 110782

for some reason they have a very odd MCInst form where the operands overlap, but
I haven't dug in to find out why yet.

llvm-svn: 110781

llvm-svn: 110780

llvm-svn: 110779

llvm-svn: 110778

expression parser.  It is now possible to type:

(lldb) expr int $i = 5; $i + 1
(int) 6
(lldb) expr $i + 2
(int) 7

The skeleton for automatic result variables is
also implemented.  The changes affect:

- the process, which now contains a 
  ClangPersistentVariables object that holds
  persistent variables associated with it
- the expression parser, which now uses
  the persistent variables during variable
  lookup
- TaggedASTType, where I loaded some commonly
  used tags into a header so that they are
  interchangeable between different clients of
  the class

llvm-svn: 110777

llvm-svn: 110776

 - We don't recognize double or NEON register names yet -- we don't have the
   infrastructure to generate the right clobbers for them.

llvm-svn: 110775

llvm-svn: 110774

implicit conversion sequences. In particular, model the "standard
conversion" from a class to its own type (or a base type) directly as
a standard conversion in the normal path *without* trying to determine
if there is a valid copy constructor. This appears to match the intent
of C++ [over.best.ics]p6 and more closely matches GCC and EDG.

As part of this, model non-lvalue reference initialization via
user-defined conversion in overloading the same way we handle it in
InitializationSequence, separating the "general user-defined
conversion" and "conversion to compatible class type" cases.

The churn in the overload-call-copycon.cpp test case is because the
test case was originally wrong; it assumed that we should do more
checking for copy constructors that we actually should, which affected
overload resolution.

Fixes PR7055. Bootstrapped okay.

llvm-svn: 110773

llvm-svn: 110772

Remove 256-bit cast built-ins and make the AVX intrinsic call llvm __builtin_shufflevector with the appropriate arguments

llvm-svn: 110771

llvm-svn: 110770

Remove AVX 256-bit unpack and interleave intrinsics now that clang is using __builtin_shufflevector for those

llvm-svn: 110769

Remove 256-bit unpack built-ins and make the AVX intrinsic call llvm __builtin_shufflevector with the appropriate arguments

llvm-svn: 110768

llvm-svn: 110767

Remove 256-bit shuffle built-ins and make the AVX intrinsic call llvm __builtin_shufflevector with the appropriate arguments

llvm-svn: 110766

llvm-svn: 110765

llvm-svn: 110764

llvm-svn: 110763

llvm-svn: 110762

llvm-svn: 110761

where we weren't accounting for the possibility that a @finally block might
have internal cleanups and therefore might write to the cleanup destination slot.

Fixes <rdar://problem/8293901>.

llvm-svn: 110760

llvm-svn: 110759

make any assumptions about when the two conditions will agree on when
to permit the loop to exit. This fixes PR7845.

llvm-svn: 110758

from inline assembly, except in cases where they had already been seen (in which
case they would get added twice).
 - I can't see how this ever worked...

llvm-svn: 110757

llvm-svn: 110756

Have GRCoreEngine record the blocks where analysis was aborted because we visited a block too many times along a given path.  This is to support the unreachable code analysis.

llvm-svn: 110755