MachineCopyPropagation doesn't understand super-register liveness well
enough to be able to remove implicit defs of super-registers.

This fixes a problem in ARM/2012-01-26-CopyPropKills.ll that is exposed
by an future TwoAddressInstructionPass change. The KILL instructions are
removed before the machine code is emitted.

llvm-svn: 169060

Don't emit a warning with an input/output parameter. We assume the user knows what they're doing here.

llvm-svn: 169059

llvm-svn: 169058

state so that all of the various clones end up rendering their
diagnostics into the same serialized-diagnostics file. This is
important when we actually want failures during module build to be
reported back to the translation unit that tried to import the
not-yet-built or out-of-date module. <rdar://problem/12565727>

llvm-svn: 169057

llvm-svn: 169056

llvm-svn: 169055

the output size is greater than the register size. No truncation occurs with
those. Reword warning to make it clearer what's the problem is.

llvm-svn: 169054

llvm-svn: 169053

llvm-svn: 169052

<rdar://problem/12780159>.

llvm-svn: 169051

llvm-svn: 169050

reversed the logic of the log2 detection routine to reduce the number of nested ifs

llvm-svn: 169049

llvm-svn: 169048

uses. APFloat::convert() takes the pointer to the fltSemantics
variable, which is later accessed it in ~APFloat() desctructor.
That is, semantics must still be alive at the moment we delete
APFloat.

Found by experimental AddressSanitizer use-after-scope checker.

llvm-svn: 169047

llvm-svn: 169046

llvm-svn: 169045

The original patch removed a bunch of code that the SjLjEHPrepare pass placed
into the entry block if all of the landing pads were removed during the
CodeGenPrepare class. The more natural way of doing things is to run the CGP
*before* we run the SjLjEHPrepare pass.

Make it so!

llvm-svn: 169044

llvm-svn: 169043

module, provide a module import stack similar to what we would get for
an include stack, e.g.,

In module 'DependsOnModule' imported from build-fail-notes.m:4:
In module 'Module' imported from DependsOnModule.framework/Headers/DependsOnModule.h:1:
Inputs/Module.framework/Headers/Module.h:15:12: note: previous definition is here
@interface Module

<rdar://problem/12696425>

llvm-svn: 169042

llvm-svn: 169041

This causes llc to repeat the module compilation N times, making it
possible to get more accurate information from -time-passes when
compiling small modules.

llvm-svn: 169040

This avoids unidentified duplicates in the pass execution time report
when a pass runs more than once in the pass manager pipeline.

llvm-svn: 169039

llvm-svn: 169038

llvm-svn: 169037

llvm-svn: 169036

Readline & gdb have a bunch of code to handle older UNIX'es with other job control mechanisms.
I didn't try to replicate that.

llvm-svn: 169032

<rdar://problem/12676084> Dump the traceback when a Python error occurs in "command script import" and the exception is not an ImportError

llvm-svn: 169031

llvm-svn: 169030

llvm-svn: 169029

llvm-svn: 169028

files are loaded.

llvm-svn: 169027

llvm-svn: 169026

reviewed by Michael Ilseman <milseman@apple.com>

llvm-svn: 169025

Codegen was failing with an assertion because of unexpected vector
operands when legalizing the selection DAG for a MUL instruction.

The asserting code was legalizing multiplies for vectors of size 128
bits. It uses a custom lowering to try and detect cases where it can
use a VMULL instruction instead of a VMOVL + VMUL.  The code was
looking for input operands to the MUL that had been sign or zero
extended. If it found the extended operands it would drop the
sign/zero extension and use the original vector size as input to a
VMULL instruction.

The code assumed that the original input vector was 64 bits so that
after dropping the extension it would fit directly into a D register
and could be used as an operand of a VMULL instruction. The input
code that trigger the failure used a vector of <4 x i8> that was
sign extended to <4 x i32>. It was not safe to drop the sign
extension in this case because the original vector is only 32 bits
wide. The fix is to insert a sign extension for the vector to reach
the required 64 bit size. In this particular example, the vector would
need to be sign extented to a <4 x i16>.

llvm-svn: 169024

For "target create" you can now specify "--no-dependents" to not track down and add all dependent shared libraries. This can be handy when doing manual symbolication. Also added the "--symfile" or "-s" for short so you can specify a module and a stand alone debug info file:

(lldb) target create --symfile /tmp/a.dSYM /usr/bin/a

Added the "--symfile" option to the "target modules add" for the same reason. These all help with manualy symbolication and expose functionality that was previously only available through the public API layer.

llvm-svn: 169023

__list::ends_with_template was giving the wrong answer for empty lists.  And __parse_unnamed_type_name wasn't properly handling the list of paramters and was not safe against incorrectly mangled lambdas (running past last).

llvm-svn: 169022

building module 'Foo' imported from..." notes (the same we we provide
"In file included from..." notes) in the diagnostic, so that we know
how this module got included in the first place. This is part of
<rdar://problem/12696425>.

llvm-svn: 169021

llvm-svn: 169020

llvm-svn: 169019

llvm-svn: 169018