We used to rely on the *eh_sjlj_setjmp instructions to mark that a function
with setjmp/longjmp exception handling clobbers all the registers.  But with
the recent reorganization of ARM EH, those eh_sjlj_setjmp instructions are
expanded away earlier, before PEI can see them to determine what registers to
save and restore.  Mark the dispatchsetup instruction in the same way, since
that instruction cannot be expanded early.  This also more accurately reflects
when the registers are clobbered.

llvm-svn: 146949

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add a NULL check for SBTarget.AttachToProcessWithName() so it will not hang.

llvm-svn: 146948

llvm-svn: 146940

llvm-svn: 146939

llvm-svn: 146938

"mov r1, r2, lsl #0" should assemble as "mov r1, r2" even though it's
not strictly legal UAL syntax. It's a common extension and the friendly
thing to do.

rdar://10604663

llvm-svn: 146937

llvm-svn: 146936

llvm-svn: 146935

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBStream APIs.

llvm-svn: 146934

hitting a submodule that was never actually created, e.g., because
that header wasn't parsed. In such cases, complain (because the
module's umbrella headers don't cover everything) and fall back to
including the header.

Later, we'll add a warning at module-build time to catch all such
cases. However, this fallback is important to eliminate assertions in
the ASTWriter when this happens.

llvm-svn: 146933

merging types by name when we can.  We still don't guarantee type name linkage
but we do it when obviously the right thing to do.  This makes LTO type names 
easier to read, for example.

llvm-svn: 146932

llvm-svn: 146931

llvm-svn: 146930

fix PR11464 by preventing the linker from mapping two different struct types from the source module onto the same opaque destination type.  An opaque type can only be resolved to one thing or another after all.

llvm-svn: 146929

llvm-svn: 146928

llvm-svn: 146927

llvm-svn: 146926

e.g., "vmov.i32 d4, #-118" can be assembled as "vmvn.i32 d4, #117"

rdar://10603913

llvm-svn: 146925

llvm-svn: 146924

llvm-svn: 146923

llvm-svn: 146922

rdar://9932658

llvm-svn: 146921

llvm-svn: 146920

llvm-svn: 146919

error. // rdar://10597832

llvm-svn: 146918

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBDebugger APIs.

llvm-svn: 146917

actually requires non-trivial cleanups, so no cleanups need to be performed.

llvm-svn: 146916

llvm-svn: 146915

unpredicated. That is, turn
 subeq  r0, r1, #1
 addne  r0, r1, #1                                                                                                                                                                                                     
into
 sub    r0, r1, #1
 addne  r0, r1, #1

For targets where conditional instructions are always executed, this may be
beneficial. It may remove pseudo anti-dependency in out-of-order execution
CPUs. e.g.
 op    r1, ...
 str   r1, [r10]        ; end-of-life of r1 as div result
 cmp   r0, #65
 movne r1, #44  ; raw dependency on previous r1
 moveq r1, #12

If movne is unpredicated, then
 op    r1, ...
 str   r1, [r10]
 cmp   r0, #65
 mov   r1, #44  ; r1 written unconditionally
 moveq r1, #12

Both mov and moveq are no longer depdendent on the first instruction. This gives
the out-of-order execution engine more freedom to reorder them.

This has passed entire LLVM test suite. But it has not been enabled for any ARM
variant pending more performance evaluation.

rdar://8951196

llvm-svn: 146914

llvm-svn: 146913

llvm-svn: 146912

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBCommandReturnObject.AppendMessage().

llvm-svn: 146911

llvm-svn: 146910

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBCommandInterpreter APIs.

llvm-svn: 146909

Fix PR5279 - don't sliently drop alignment information on stores of types that have alignment less than the natural alignment of the type when it comes from a typedef.

llvm-svn: 146908

llvm-svn: 146907

llvm-svn: 146906

format. It's no longer being used, now that we have a new
implementation of redeclaration chains.

llvm-svn: 146905

But, warn too. // rdar://10597832

llvm-svn: 146904

(more general) fix-up of definition data pointers.

llvm-svn: 146903