llvm-svn: 127321

alloca as both integer and floating-point vectors of the same size. Bugpoint is
not cooperating with me, but I'll try to find a manual testcase tomorrow.

llvm-svn: 127320

llvm-svn: 127319

gave up when I realized I couldn't come up with a good name for what the
refactored function would be, to describe what it does.

This is PR9343 test12, which is test3 with arguments reordered. Whoops!

llvm-svn: 127318

a union of a float, <2 x float>, and <4 x float>. This mostly comes up with the
use of vector intrinsics, especially in NEON when programmers know the layout of
the register file. This enables codegen to eliminate a lot of the subregister
traffic it would otherwise generate.

This commit only enables this for a small number of floating-point cases, but a
lot more integer cases. I assume this is okay for all ports, but I did not do
extensive testing of the quality of code involving i512 vectors and the like. If
there is a use case where this generates worse code than before, let me know and
we can scale it back.

This fixes <rdar://problem/9036264>.

llvm-svn: 127317

more complicated.

llvm-svn: 127316

When deserializing CXXBaseSpecifiers (and offsets), make sure to walk the chain in the correct order.

llvm-svn: 127315

simplify the logic of initializing function parameters so that we don't need
both a variable declaration and a type in FunctionArgList.  This also means
that we need to propagate the CGFunctionInfo down in a lot of places rather
than recalculating it from the FAL.  There's more we can do to eliminate
redundancy here, and I've left FIXMEs behind to do it.

llvm-svn: 127314

K&R-style default argument promotion.

llvm-svn: 127313

llvm-svn: 127312

llvm-svn: 127311

llvm-svn: 127310

Cygwin's ctype.h says;
/* These macros are intentionally written in a manner that will trigger
   a gcc -Wall warning if the user mistakenly passes a 'char' instead
   of an int containing an 'unsigned char'.
   (snip) */

llvm-svn: 127308

llvm-svn: 127307

INT_MIN % -1.

llvm-svn: 127306

llvm-svn: 127304

Chris Jefferson found a defect in the C++0x working draft by trying to run libc++ against boost.  I've submitted an issue to the LWG, and this commit attempts to implement the proposed resolution of that defect report.  I'd point to the issue but it hasn't been put into the LWG list yet.  The title of the issue will be: Stage 2 accumulate incompatibilty

llvm-svn: 127303

ARM disassembler was wrong, causing the disassembler to fail
to initialize.

llvm-svn: 127302

This will we used for keeping register allocator data structures up to date
while LiveRangeEdit is trimming live intervals.

llvm-svn: 127300

reachable uses, but there still might be uses in dead blocks.  Use the
standard solution of replacing all the uses with undef.  This is
a rare case because it's very sensitive to phase ordering in SimplifyCFG.

llvm-svn: 127299

llvm-svn: 127298

* Add tests for VSRI and VSLI.

llvm-svn: 127297

llvm-svn: 127295

llvm-svn: 127294

* Update the NEON shift instruction test to expect what 'as' produces.

llvm-svn: 127293

size_t
SBProcess::ReadMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error);

llvm-svn: 127292

llvm-svn: 127291

It fails when running within the context of the test suite, but succeeds
when running alone.

llvm-svn: 127290

should report the original file name for contents of files that were overriden by other files,
otherwise it should report the name of the new file. Default is true.

Also add similar field in PreprocessorOptions and pass similar parameter in ASTUnit::LoadFromCommandLine.

llvm-svn: 127289

static analyzer: Fix use-after-free bug in RegionStore involving LazyCompoundValueData not reference counting Store objects.

llvm-svn: 127288

LiveRangeEdit::eliminateDeadDefs() will eventually be used by coalescing,
splitting, and spilling for dead code elimination. It can delete chains of dead
instructions as long as there are no dependency loops.

llvm-svn: 127287

an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a "default" platform that will be
used unless a new platform is selected. Platforms are responsible for things
such as:
- getting process information by name or by processs ID
- finding platform files. This is useful for remote debugging where there is 
  an SDK with files that might already or need to be cached for debug access.
- getting a list of platform supported architectures in the exact order they
  should be selected. This helps the native x86 platform on MacOSX select the
  correct x86_64/i386 slice from universal binaries.
- Connect to remote platforms for remote debugging
- Resolving an executable including finding an executable inside platform
  specific bundles (macosx uses .app bundles that contain files) and also
  selecting the appropriate slice of universal files for a given platform.

So by default there is always a local platform, but remote platforms can be
connected to. I will soon be adding a new "platform" command that will support
the following commands:
(lldb) platform connect --name machine1 macosx connect://host:port
Connected to "machine1" platform.
(lldb) platform disconnect macosx

This allows LLDB to be well setup to do remote debugging and also once 
connected process listing and finding for things like:
(lldb) process attach --name x<TAB>

The currently selected platform plug-in can now auto complete any available
processes that start with "x". The responsibilities for the platform plug-in
will soon grow and expand.

llvm-svn: 127286

llvm-svn: 127285

llvm-svn: 127284

llvm-svn: 127283

llvm-svn: 127282

llvm-svn: 127278

llvm-svn: 127272

llvm-svn: 127270

llvm-svn: 127269