llvm-svn: 164920

Change getX86SubSuperRegister to take an MVT::SimpleValueType rather than an EVT and add llvm_unreachable to the switches. Helps it compile to dramatically better code.

llvm-svn: 164919

Fun fact: The CBE learned how to deal with this situation before it was removed.

llvm-svn: 164918

CodeGen: Copy tail padding when we're not dealing with a trivial copy assign or move assign operator.

This fixes a regression from r162254, the optimizer has problems reasoning
about the smaller memcpy as it's often not safe to widen a store but making it
smaller is.

llvm-svn: 164917

llvm-svn: 164916

llvm-svn: 164915

source of false positives due to globals being declared in a header with some
kind of incomplete (small) type, but the actual definition being bigger.

llvm-svn: 164912

llvm-svn: 164911

A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work.  We only handle these cases:

1. Consecutive stores where the values and consecutive loads. For example:
 int a = p->a;
 int b = p->b;
 q->a = a;
 q->b = b;

2. Consecutive stores where the values are constants. Foe example:
 q->a = 4;
 q->b = 5;

llvm-svn: 164910

llvm-svn: 164909

llvm-svn: 164908

llvm-svn: 164907

llvm-svn: 164906

llvm-svn: 164905

llvm-svn: 164904

llvm-svn: 164903

llvm-svn: 164902

llvm-svn: 164900

llvm-svn: 164899

llvm-svn: 164898

llvm-svn: 164897

broken as of r164656 as TemplateArgument::getAsDecl() now asserts
instead of returning NULL for other template arugment kinds.

llvm-svn: 164896

use it to suggest appropriate macro for __attribute__((deprecated)) in
-Wdocumentation-deprecated-sync.

llvm-svn: 164892

alignment could lose it due to the alloca type moving down to a much
smaller alignment guarantee.

Now SROA will actively compute a proper alignment, factoring the target
data, any explicit alignment, and the offset within the struct. This
will in some cases lower the alignment requirements, but when we lower
them below those of the type, we drop the alignment entirely to give
freedom to the code generator to align it however is convenient.

Thanks to Duncan for the lovely test case that pinned this down. =]

llvm-svn: 164891

buildbots.  Original commit message:

A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work.  We only handle these cases:

1. Consecutive stores where the values and consecutive loads. For example:
  int a = p->a;
  int b = p->b;
  q->a = a;
  q->b = b;

2. Consecutive stores where the values are constants. Foe example:
  q->a = 4;
  q->b = 5;

llvm-svn: 164890

llvm-svn: 164889

When attaching to a remote system that does not look like a typical vendor system, and no
executable binary was specified to lldb, check a couple of fixed locations where kernels
running in ASLR mode (slid in memory to a random address) store their load addr when booted
in debug mode, and relocate the symbols or load the kernel wholesale from the host computer
if we can find it.  

<rdar://problem/7714201>

llvm-svn: 164888

Tidy up to match coding standards. Remove 'else' after 'return' and moving operators to end of preceding line. No functional change intended.

llvm-svn: 164887

Replace a couple if/elses around similar calls with conditional operators on the varying arguments. No functional change.

llvm-svn: 164886

A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work.  We only handle these cases:

1. Consecutive stores where the values and consecutive loads. For example:
  int a = p->a;
  int b = p->b;
  q->a = a;
  q->b = b;

2. Consecutive stores where the values are constants. Foe example:
  q->a = 4;
  q->b = 5;

llvm-svn: 164885

loaded at a random offset).

To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.

I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.

<rdar://problem/7714201>

llvm-svn: 164881

llvm-svn: 164880

llvm-svn: 164879

runtime, we read method signatures for both class
and instance methods out of the runtime data.

(lldb) fr var str
(NSString *) str = 0x0000000105000180 @"Hello from '/Volumes/Data/projects/lldb/test/lang/objc/foundation/a.out'"
(lldb) expr str.length
(unsigned long long) $0 = 72
(lldb) expr [NSString stringWithCString:"Hello world!" encoding:1]
(id) $1 = 0x0000000105100050
(lldb) po $1
$1 = 0x0000000105100050 Hello world!

(lldb) fr var array1
(NSArray *) array1 = 0x000000010010a6e0 @"3 objects"
(lldb) expr array1.count
(unsigned long long) $0 = 3
(lldb) expr [array1 objectAtIndex:2]
(id) $1 = 0x00000001000025d0
(lldb) po $1
$1 = 0x00000001000025d0 array1 object3

Notice that both regular and property-style notation
work.  I still need to add explicit support for
properties with non-default setters/getters.

This information is only queried if an Objective-C
object does not have debug information for a complete
type available.  Otherwise we query debug information
as usual.

llvm-svn: 164878

This reverts commit 6f61df3e7256413dcb99afb9673f4206e3c4992c.

llvm-svn: 164877

This reverts commit 0006ba445962621ed82ec84400a6b978205a3fbc.

llvm-svn: 164876

This reverts commit 580cd17f256259f39a382e967173f34d68e73859.

llvm-svn: 164875

an inclusion directive was automatically turned into a module import, and
PPCallbacks::moduleImport() for an explicit module import.

llvm-svn: 164874

llvm-svn: 164873

is the same as the suggested one when looking up the include filename.

llvm-svn: 164872