[AAarch64] Optimize CSINC-branch sequence

Peephole optimization that generates a single conditional branch
for csinc-branch sequences like in the examples below. This is
possible when the csinc sets or clears a register based on a condition
code and the branch checks that register. Also the condition
code may not be modified between the csinc and the original branch.

Examples:

1. Convert csinc w9, wzr, wzr, <CC>;tbnz w9, #0, 0x44
   to b.<invCC>

2. Convert csinc w9, wzr, wzr, <CC>; tbz w9, #0, 0x44
   to b.<CC>

rdar://problem/18506500

llvm-svn: 219742

[LoopVectorize] Ignore @llvm.assume for cost estimates and legality

A few minor changes to prevent @llvm.assume from interfering with loop
vectorization. First, treat @llvm.assume like the lifetime intrinsics, which
are scalarized (but don't otherwise interfere with the legality checking).
Second, ignore the cost of ephemeral instructions in the loop (these will go
away anyway during CodeGen).

Alignment assumptions and other uses of @llvm.assume can often end up inside of
loops that should be vectorized (this is not uncommon for assumptions generated
by __attribute__((align_value(n))), for example).

llvm-svn: 219741

MS Compat: interpose vadefs.h to fix definitions of _crt_va_{start,end,arg} (PR21247)

Differential revision: http://reviews.llvm.org/D5784

llvm-svn: 219740

MC, COFF: Make bigobj test compatible with python3

No functionality change intended.

llvm-svn: 219739

[X86][SSE] pslldq/psrldq shuffle mask decodes

Patch to provide shuffle decodes and asm comments for the sse pslldq/psrldq SSE2/AVX2 byte shift instructions.

Differential Revision: http://reviews.llvm.org/D5598

llvm-svn: 219738

MC: Rewrite bigobj test in python

This makes the test easier to work with.  No functionality change
intended.

llvm-svn: 219737

DebugInfo: Lazily built static member variable declarations should use the canonical declaration for line/file information.

When lazily constructing static member variable declarations (when
the vtable optimization fires and the definition of the type is omitted
(or built later, lazily), but the out of line definition of the static
member is provided and must be described in debug info) ensure we use
the canonical declaration when computing the file, line, etc for that
declaration (rather than the definition, which is also a declaration,
but not the canonical one).

llvm-svn: 219736

ARM: remove ARM/Thumb distinction for preferred alignment.

Thumb1 has legitimate reasons for preferring 32-bit alignment of types
i1/i8/i16, since the 16-bit encoding of "add rD, sp, #imm" requires #imm to be
a multiple of 4. However, this is a trade-off betweem code size and RAM usage;
the DataLayout string is not the best place to represent it even if desired.

So this patch removes the extra Thumb requirements, hopefully making ARM and
Thumb completely compatible in this respect.

llvm-svn: 219735

ARM: remove ARM/Thumb distinction for preferred alignment.

Thumb1 has legitimate reasons for preferring 32-bit alignment of types
i1/i8/i16, since the 16-bit encoding of "add rD, sp, #imm" requires #imm to be
a multiple of 4. However, this is a trade-off betweem code size and RAM usage;
the DataLayout string is not the best place to represent it even if desired.

So this patch removes the extra Thumb requirements, hopefully making ARM and
Thumb completely compatible in this respect.

llvm-svn: 219734

ARM: allow misaligned local variables in Thumb1 mode.

There's no hard requirement on LLVM to align local variable to 32-bits, so the
Thumb1 frame handling needs to be able to deal with variables that are only
naturally aligned without falling over.

llvm-svn: 219733

Be smarter when parsing variable declarations with unknown types.

Specifically, avoid typo-correcting the variable name into a type before
typo-correcting the actual type name in the declaration. Doing so
results in a very unpleasant cascade of errors, with the typo correction
of the actual type name being buried in the middle.

llvm-svn: 219732

Create a process launcher abstraction.

This implements Host::LaunchProcess for windows, and in doing so
does some minor refactor to move towards a more modular process
launching design.

The original motivation for this is that launching processes on
windows needs some very windows specific code, which would live
most appropriately in source/Host/windows somewhere.  However,
there is already some common code that all platforms use when
launching a process before delegating to the platform specific
stuff, which lives in source/Host/common/Host.cpp which would
be nice to reuse without duplicating.

This commonality has been abstracted into MonitoringProcessLauncher,
a class which abstracts out the notion of launching a process using
an arbitrary algorithm, and then monitoring it for state changes.

The windows specific launching code lives in ProcessLauncherWindows,
and the posix specific launching code lives in ProcessLauncherPosix.
When launching a process MonitoringProcessLauncher is created, and
then an appropriate delegate launcher is created and given to the
MonitoringProcessLauncher.

Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5781

llvm-svn: 219731

Fix a path concatenation issue related to windows paths.

llvm-svn: 219730

Add a test for writing COFF BigObj

llvm-svn: 219729

When PlatformDarwinKernel::ExamineKextForMatchingUUID is given
a FileSpec, UUID, and ArchSpec, and it's opening all the kexts
with the same bundle id to see if they're a match, don't set
the Arch in the ModuleSpec.  If Module::GetObjectFile() sees
that the architecture of the kext is a mismatch for the arch
we're looking for, it'll spew a warning message to the dev (r217251).

Rely on the UUID match to get the correct file if we have
a UUID -- we'll get no warning if it's a mismatch.

<rdar://problem/18641477>

llvm-svn: 219728

Use isa<> and cast<> instead of definition().

No functionality change intended.

llvm-svn: 219727

[FastISel][AArch64] Add custom lowering for GEPs.

This is mostly a copy of the existing FastISel GEP code, but on AArch64 we bail
out even for simple cases, because the standard fastEmit functions don't cover
MUL and ADD is lowered inefficientily.

llvm-svn: 219726

[x86 asm] allow fwait alias in both At&t and Intel modes (PR21208)

Differential Revision: http://reviews.llvm.org/D5741

llvm-svn: 219725

Remove dead code.

Because we use cast<> at the beginning of this function, it will
abort there if a given atom is not a DefinedAtom.

In the switch statement, we checked if a given atom is a DefinedAtom
again by evaluating definition() == Atom::definitionRegular.
This was always true. So we can remove the outer switch statement.

llvm-svn: 219724

Use isa<> instead of checking return value of definition().

definition() is supposed to be used through isa, dyn_cast or cast.
It's better to not call that directly.

llvm-svn: 219723

Fix compiler-rt build on FreeBSD 10.1

We have to #define _WANT_RTENTRY to get struct rtentry, and add headers
that it depends on.

SIOCADDRT and SIOCDELRT also do not exist in FreeBSD 10.1 and were removed
in FreeBSD rev. 263203:

  Garbage collect long time obsoleted (or never used) stuff from routing
  API.

Differential Revision: http://reviews.llvm.org/D5703

llvm-svn: 219722

Re-enable ASAN/UBSAN tests on ARM, with VFP3 they began to pass

When compiling with -mfpu=vfpv3, those tests began to pass, like the others
with "Illegal Instruction" error, so removing the XFAIL from them should
get the bot green (and have more tests!).

llvm-svn: 219721

ARM: set preferred aggregate alignment to 32 universally.

Before, ARM and Thumb mode code had different preferred alignments, which could
lead to some rather unexpected results. There's justification for reducing it
from the default 64-bits (wasted space), but I don't think there is for going
below 32-bits.

There's no actual ABI change here, just to reassure people.

llvm-svn: 219720

ARM: set preferred aggregate alignment to 32 universally.

Before, ARM and Thumb mode code had different preferred alignments, which could
lead to some rather unexpected results. There's justification for reducing it
from the default 64-bits (wasted space), but I don't think there is for going
below 32-bits.

There's no actual ABI change here, just to reassure people.

llvm-svn: 219719

[CFL-AA] CFL-AA should not assert on an va_arg instruction

The CFL-AA implementation was missing a visit* routine for va_arg instructions,
causing it to assert when run on a function that had one. For now, handle these
in a conservative way.

Fixes PR20954.

llvm-svn: 219718

Optimize away fabs() calls when input is squared (known positive).

Eliminate library calls and intrinsic calls to fabs when the input
is a squared value.

Note that no unsafe-math / fast-math assumptions are needed for
this optimization.

Differential Revision: http://reviews.llvm.org/D5777

llvm-svn: 219717

[FastISel][AArch64] Fix sign-/zero-extend folding when SelectionDAG is involved.

Sign-/zero-extend folding depended on the load and the integer extend to be
both selected by FastISel. This cannot always be garantueed and SelectionDAG
might interfer. This commit adds additonal checks to load and integer extend
lowering to catch this.

Related to rdar://problem/18495928.

llvm-svn: 219716

Add complex multiply/divide functions to arm64 iOS libclang_rt libraries.

Clang r219557 introduces libcalls to complex multiply/divide functions.
Since these functions are not available in iOS for arm64 devices, add them to
the static libraries.

llvm-svn: 219715

Factor code into CXXRecordDecl::getTemplateInstantiationPattern() helper

This moves some code from SemaType.cpp's hasVisibleDefinition() into
DeclCXX.cpp so that it can be used elsewhere. I found one other instance
of code trying to do the same thing, there are probably more. Search for
getInstantiatedFrom() to try to find more.

No functionality change.

Reviewed By: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D5783

llvm-svn: 219714

InstCombine: Don't miscompile X % ((Pow2 << A) >>u B)

We assumed that A must be greater than B because the right hand side of
a remainder operator must be nonzero.

However, it is possible for A to be less than B if Pow2 is a power of
two greater than 1.

Take for example:
i32 %A = 0
i32 %B = 31
i32 Pow2 = 2147483648

((Pow2 << 0) >>u 31) is non-zero but A is less than B.

This fixes PR21274.

llvm-svn: 219713

Patch to warn on interger overflow in presence of
implicit casts. Reviewed by Reid Kleckner.
rdar://18405357

llvm-svn: 219712

Fixed stdio redirection within LLDB to "do the right thing" in all cases.

The main issue was if you didn't specify all three (stdin/out/err), you would get file actions added to the launch that would always use the pseudo terminal. This is now fixed.

Also fixed the test suite test that handles IO to test redirecting things individually and all together and in other combinations to make sure we don't regress.

<rdar://problem/18638226>

llvm-svn: 219711

Reapply "R600: Add new intrinsic to read work dimensions"

This effectively reverts revert 219707. After fixing the test to work with
new function name format and renamed intrinsic.

Reviewed-by: Tom Stellard <tom@stellard.net>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 219710

Use llvm::make_unique.

llvm-svn: 219709

Revert "r216914 - Revert: [APFloat] Fixed a bug in method 'fusedMultiplyAdd'"

Reapply r216913, a fix for PR20832 by Andrea Di Biagio. The commit was reverted
because of buildbot failures, and credit goes to Ulrich Weigand for isolating
the underlying issue (which can be confirmed by Valgrind, which does helpfully
light up like the fourth of July). Uli explained the problem with the original
patch as:

  It seems the problem is calling multiplySignificand with an addend of category
  fcZero; that is not expected by this routine.  Note that for fcZero, the
  significand parts are simply uninitialized, but the code in (or rather, called
  from) multiplySignificand will unconditionally access them -- in effect using
  uninitialized contents.

This version avoids using a category == fcZero addend within
multiplySignificand, which avoids this problem (the Valgrind output is also now
clean).

Original commit message:

[APFloat] Fixed a bug in method 'fusedMultiplyAdd'.

When folding a fused multiply-add builtin call, make sure that we propagate the
correct result in the case where the addend is zero, and the two other operands
are finite non-zero.

Example:
  define double @test() {
    %1 = call double @llvm.fma.f64(double 7.0, double 8.0, double 0.0)
    ret double %1
  }

Before this patch, the instruction simplifier wrongly folded the builtin call
in function @test to constant 'double 7.0'.
With this patch, method 'fusedMultiplyAdd' correctly evaluates the multiply and
propagates the expected result (i.e. 56.0).

Added test fold-builtin-fma.ll with the reproducible from PR20832 plus extra
test cases to verify the behavior of method 'fusedMultiplyAdd' in the presence
of NaN/Inf operands.

This fixes PR20832.

llvm-svn: 219708

Revert "R600: Add new intrinsic to read work dimensions"

This reverts commit r219705.

CodeGen/R600/work-item-intrinsics.ll was failing on linux.

llvm-svn: 219707

Remove unused member variable.

Fixes pr20904.

llvm-svn: 219706

R600: Add new intrinsic to read work dimensions

v2: Add SI lowering
    Add test

v3: Place work dimensions after the kernel arguments.
v4: Calculate offset while lowering arguments
v5: rebase
v6: change prefix to AMDGPU

Reviewed-by: Tom Stellard <tom@stellard.net>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 219705

R600: FMA is VecALU only instruction

Reviewed-by: Tom Stellard <tom@stellard.net>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 219704

Finish getting Mips fast-isel to match up with AArch64 fast-isel

Summary:
In order to facilitate use of common code, checking by reviewers of other fast-isel ports, and hopefully to eventually move most of Mips and other fast-isel ports into target independent code, I've tried to get the two implementations to line up.

There is no functional code change. Just methods moved in the file to be in the same order as in AArch64.

Test Plan: No functional change.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits, aemerson, rfuhler

Differential Revision: http://reviews.llvm.org/D5692

llvm-svn: 219703

DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.

Let me tell you a tale...

Originally committed in r211723 after discovering a nasty case of weird
scoping due to inlining, this was reverted in r211724 after it fired in
ASan/compiler-rt.

(minor diversion where I accidentally committed/reverted again in
r211871/r211873)

After further testing and fixing bugs in ArgumentPromotion (r211872) and
Inlining (r212065) it was recommitted in r212085. Reverted in r212089
after the sanitizer buildbots still showed problems.

Fixed another bug in ArgumentPromotion (r212128) found by this
assertion.

Recommitted in r212205, reverted in r212226 after it crashed some more
on sanitizer buildbots.

Fix clang some more in r212761.

Recommitted in r212776, reverted in r212793. ASan failures.
Recommitted in r213391, reverted in r213432, trying to reproduce flakey
ASan build failure.

Fixed bugs in r213805 (ArgPromo + DebugInfo), r213952
(LiveDebugVariables strips dbg_value intrinsics in functions not
described by debug info).

Recommitted in r214761, reverted in r214999, flakey failure on Windows
buildbot.

Fixed DeadArgElimination + DebugInfo bug in r219210.

Recommitted in r219215, reverted in r219512, failure on ObjC++ atomic
properties in the test-suite on Darwin.

Fixed ObjC++ atomic properties issue in Clang in r219690.

[This commit is provided 'as is' with no hope that this is the last time
I commit this change either expressed or implied]

llvm-svn: 219702

Skip asan test on FreeBSD

The build fails due to missing asan runtime in the FreeBSD base system.
Instead of marking it expected fail, just skip until we have the runtime
available.

llvm.org/pr21136

llvm-svn: 219701

Remove method that is identical to the base class one.

llvm-svn: 219700

[UBSan] XFAIL test added in r219642 on Darwin

llvm-svn: 219699

R600/SI: Use DS offsets for constant addresses

Use 0 as the base address for a constant address, so if
we have a constant address we can save moves and form
read2/write2s.

llvm-svn: 219698

CodeGen: correct block mangling in ObjC

Mangling for blocks defined within blocks in an ObjectiveC context were also
broken by SVN r219393.  Because the code in mangleName assumed that the code was
either C or C++, we would trigger assertions when trying to mangle the inner
blocks in an ObjectiveC context.

Add a test and use the ObjectiveC specific mangling when dealing with an
ObjectiveC method declaration.

llvm-svn: 219697

CodeGen: correct mangling for blocks

This addresses a regression introduced with SVN r219393.  A block may be
contained within another block.  In such a scenario, we would end up within a
BlockDecl, which is not a NamedDecl (as the names are synthesised).  The cast to
a NamedDecl of the DeclContext would then assert as the types are unrelated.

Restore the mangling behaviour to that prior to SVN r219393.  If the current
block is contained within a BlockDecl, walk up to the parent DeclContext,
recursively, until we have a non-BlockDecl.  This is expected to be a NamedDecl.
Add in a couple of asserts to ensure that the assumption that we only encounter
a block within a NamedDecl or a BlockDecl.

llvm-svn: 219696

Revert "Fix stuff... again."

Accidental commit.

This reverts commit r219693.

llvm-svn: 219695

Revert some parts of r196288 that were confusing and untested.

If we figure out why they should be here, let's add some testing of some
kind so we can better demonstrate why it's needed.

llvm-svn: 219694

Fix stuff... again.

llvm-svn: 219693

Formatting for prior commit

llvm-svn: 219692

[SystemZ] Address review comments for r219679

llvm-svn: 219691

DebugInfo: Don't leak location information from one function into the prologue of the next function.

CodeGenFunction objects aren't really designed to be reused for more
than one function, and doing so can leak debug info location information
from one function into the prologue of the next.

Add an assertion in to catch reuses of CodeGenFunction, which
surprisingly only caught the ObjC atomic getter/setter cases. Fix those
and add a test to demonstrate the issue.

The test is a bit slim, because we're just testing for the absence of a
debug location on the prologue instructions, which by itself probably
wouldn't be the end of the world - but the particular debug location
that was ending up there was for the previous function's last
instruction. This produced debug info for another function within this
function, which is something I'm trying to remove all cases of as its a
substantial source of bugs, especially around inlining (see r219215).

llvm-svn: 219690

Fix dotest.py test runner exit code to return non-zero on failure/error.

This addresses this bug:
http://www.llvm.org/bugs/show_bug.cgi?id=21267

Which has been broken since svn r215256 on Aug 8 2014.

DO NOT REVERT THIS COMMIT EVEN IF IT CREATES TEST FAILURES.

The test failures are a result of accumulation of hidden failures
that were masked by the bug this change fixes.  Most of our test
runners as part of build testing rely on dotest.py returning non-zero to indicate
some kind of errant test run.  Thus, we have been flying blind
since Aug 8 2014.

llvm-svn: 219689

[LVI] Check for @llvm.assume dominating the edge branch

When LazyValueInfo uses @llvm.assume intrinsics to provide edge-value
constraints, we should check for intrinsics that dominate the edge's branch,
not just any potential context instructions. An assumption that dominates the
edge's branch represents a truth on that edge. This is specifically useful, for
example, if multiple predecessors assume a pointer to be nonnull, allowing us
to simplify a later null comparison.

The test case, and an initial patch, were provided by Philip Reames. Thanks!

llvm-svn: 219688

Revert r219638, (r219640 and r219676), "Removing the static destructor from ManagedStatic.cpp by controlling the allocation and de-allocation of the mutex."

It caused hang-up on msc17 builder, probably deadlock.

llvm-svn: 219687

[AVX512] Extended avx512_binop_rm to DQ/VL subsets.
Added encoding tests.

llvm-svn: 219686

[AVX512] Extended avx512_binop_rm to BW/VL subsets.
Added encoding tests.

llvm-svn: 219685

[AArch64] Fix crash with empty/pseudo-only blocks in A53 erratum (835769) workaround

llvm-svn: 219684

[sanitizer] Fix a crash in FP unwinder on ARM.

This change fixes 2 issues in the fast unwinder from r217079:
* A crash if a frame pointer points below current stack head, but
  inside the current thread stack limits. That memory may be
  unmapped. A check for this was lost in r217079.
* The last valid stack frame (the first one with an invalid next
  frame pointer) is always interpreted as a GCC layout frame. This
  results in garbled last PC in the (expected) case when the last
  frame has LLVM layout.

llvm-svn: 219683

[llvm-symbolizer] Minor typedef cleanup. NFC.

llvm-svn: 219682

Fix silly commit to disable test on ARM

llvm-svn: 219681

Disable failing ASAN LongJump test on ARM

Updated the URL to reflect information on the problem as well as build the
case for ARM. This seems to be a wider problem, not ARM or PPC specific.

llvm-svn: 219680

[SystemZ] Add test case to verify default use of integrated assembler

llvm-svn: 219679

tsan: remove trailing whitespace

llvm-svn: 219678

[asan] Add fast_unwind_on_check flag.

Allows to specify the unwinder to use for CHECK failures. Previous behaviour
was to use the "fatal" unwinder.
As compiler-rt is built without frame pointers, only the slow unwinder
really makes sense here, and it is the default.

llvm-svn: 219677

Threading.h: Use \tparam for template parameters. [-Wdocumentation]

llvm-svn: 219676

tsan: refactor atexit handling
The current handling (manual execution of atexit callbacks)
is overly complex and leads to constant problems due to mutual ordering of callbacks.
Instead simply wrap callbacks into our wrapper to establish
the necessary synchronization.
Fixes issue https://code.google.com/p/thread-sanitizer/issues/detail?id=80

llvm-svn: 219675

Grab the subtarget info off of the MachineFunction rather than
indirecting through the TargetMachine.

llvm-svn: 219674

Use the triple to figure out if this is a darwin target, not
the subtarget.

llvm-svn: 219673

Remove unnecessary TargetMachine.h includes.

llvm-svn: 219672

Grab the subtarget and subtarget dependent variables off of
MachineFunction rather than TargetMachine.

llvm-svn: 219671

Grab the subtarget and subtarget dependent variables off of
MachineFunction rather than TargetMachine.

llvm-svn: 219670

Instead of the TargetMachine cache the MachineFunction
and TargetRegisterInfo in the peephole optimizer. This
makes it easier to grab subtarget dependent variables off
of the MachineFunction rather than the TargetMachine.

llvm-svn: 219669

Access subtarget specific variables off of the MachineFunction's
cached subtarget and not the TargetMachine.

llvm-svn: 219668

Add lld to the parallel set of directories since it doesn't depend
on any of the other tools directories.

llvm-svn: 219667

Access the subtarget off of the MachineFunction via the DAG
scheduler or via the SelectionDAG if available. Otherwise
grab the subtarget off of the MachineFunction by going up
the parent chain.

llvm-svn: 219666

[AArch64]Select wide immediate offset into [Base+XReg] addressing mode
e.g Currently we'll generate following instructions if the immediate is too wide:
    MOV  X0, WideImmediate
    ADD  X1, BaseReg, X0
    LDR  X2, [X1, 0]

    Using [Base+XReg] addressing mode can save one ADD as following:
    MOV  X0, WideImmediate
    LDR  X2, [BaseReg, X0]

    Differential Revision: http://reviews.llvm.org/D5477

llvm-svn: 219665

Re-apply "Frontend: Extract SerializedDiagnosticReader out of CXLoadedDiagnostic (NFC)"

I'd mispelled "Bitcode/BitCodes.h" before, and tested on a case
insensitive filesystem.

This reverts commit r219649, effectively re-applying r219647 and
r219648.

llvm-svn: 219664

Remove the use and member variable of the TargetMachine from
MachineLICM as we can get the same data off of the MachineFunction.

llvm-svn: 219663

Have MachineInstrBundle use the MachineFunction for subtarget
access rather than the TargetMachine.

llvm-svn: 219662

Access the subtarget off of the MachineFunction rather than
through the TargetMachine.

llvm-svn: 219661

Use PARALLEL_DIRS instead of DIRS in the Makefile
based build since the subdirectories all appear to
have no inter-directory dependencies. This speeds
up parallel makefile builds greatly.

llvm-svn: 219660

Extend -Rmodule-build to also remark when module building finishes.

In cases of nested module builds, or when you care how long module builds take,
this information was not previously easily available / obvious.

llvm-svn: 219658

[modules] Merging for class-scope using-declarations.

llvm-svn: 219657

Switch to select optimization for two-case switches

This is the same optimization of r219233 with modifications to support PHIs with multiple incoming edges from the same block
and a test to check that this condition is handled.

llvm-svn: 219656

[mach-o] Add Pass to create are shim Atoms for ARM interworking.

Arm code has two instruction encodings "thumb" and "arm".  When branching from
one code encoding to another, you need to use an instruction that switches
the instruction mode.  Usually the transition only happens at call sites, and
the linker can transform a BL instruction in BLX (or vice versa).  But if the
compiler did a tail call optimization and a function ends with a branch (not
branch and link), there is no pc-rel BX instruction.

The ShimPass looks for pc-rel B instructions that will need to switch mode.
For those cases it synthesizes a shim which does the transition, then modifies
the original atom with the B instruction to target to the shim atom.

llvm-svn: 219655

This adds a "batch mode" to lldb kinda like the gdb batch mode.  It will quit the debugger
after all the commands have been executed except if one of the commands was an execution control
command that stopped because of a signal or exception.

Also adds a variant of SBCommandInterpreter::HandleCommand that takes an SBExecutionContext.  That
way you can run an lldb command targeted at a particular target, thread or process w/o having to
select same before running the command.

Also exposes CommandInterpreter::HandleCommandsFromFile to the SBCommandInterpreter API, since that
seemed generally useful.

llvm-svn: 219654

Don't include DFAPacketizer in TargetInstrInfo, there's no reason.

llvm-svn: 219653

Include map into the A15SDOptimizer rather than pick it up
transitively from the DFAPacketizer via TargetInstrInfo.h.

llvm-svn: 219652

Remove the TargetMachine from DFAPacketizer since it was only
being used to grab subtarget specific things that we can grab
from the MachineFunction anyhow.

llvm-svn: 219650

Revert "Frontend: Extract SerializedDiagnosticReader out of CXLoadedDiagnostic (NFC)"

The bots can't seem to find an include file. Reverting for now and
I'll look into it in a bit.

This reverts commits r219647 and r219648.

llvm-svn: 219649

Frontend: Try to fix cmake builders after r219647

Looks like I missed a dependency here.

llvm-svn: 219648

Frontend: Extract SerializedDiagnosticReader out of CXLoadedDiagnostic (NFC)

We currently read serialized diagnostics directly in the C API, which
makes it difficult to reuse this logic elsewhere. This extracts the
core of the serialized diagnostic parsing logic into a base class that
can be subclassed using a visitor pattern.

llvm-svn: 219647

Introduce Go coding standards for LLVM.

Rather than define our own standards, we adopt a set of best practices that
are already in use by the Go community.

Differential Revision: http://reviews.llvm.org/D5761

llvm-svn: 219646

fix formatting; NFC

llvm-svn: 219645

Add some optional passes around the vectorizer to both better prepare
the IR going into it and to clean up the IR produced by the vectorizers.

Note that these are *off by default* right now while folks collect data
on whether the performance tradeoff is reasonable.

In a build of the 'opt' binary, I see about 2% compile time regression
due to this change on average. This is in my mind essentially the worst
expected case: very little of the opt binary is going to *benefit* from
these extra passes.

I've seen several benchmarks improve in performance my small amounts due
to running these passes, and there are certain (rare) cases where these
passes make a huge difference by either enabling the vectorizer at all
or by hoisting runtime checks out of the outer loop. My primary
motivation is to prevent people from seeing runtime check overhead in
benchmarks where the existing passes and optimizers would be able to
eliminate that.

I've chosen the sequence of passes based on the kinds of things that
seem likely to be relevant for the code at each stage: rotaing loops for
the vectorizer, finding correlated values, loop invariants, and
unswitching opportunities from any runtime checks, and cleaning up
commonalities exposed by the SLP vectorizer.

I'll be pinging existing threads where some of these issues have come up
and will start new threads to get folks to benchmark and collect data on
whether this is the right tradeoff or we should do something else.

llvm-svn: 219644

Introduce LLVMWriteBitcodeToMemoryBuffer C API function.

llvm-svn: 219643

Sanitize upcasts and conversion to virtual base.

This change adds UBSan check to upcasts. Namely, when we
perform derived-to-base conversion, we:
1) check that the pointer-to-derived has suitable alignment
   and underlying storage, if this pointer is non-null.
2) if vptr-sanitizer is enabled, and we perform conversion to
   virtual base, we check that pointer-to-derived has a matching vptr.

llvm-svn: 219642

Resolve non-pointer isas for metaclasses.
Patch by Enrico Granata.
<rdar://problem/18618298>

llvm-svn: 219641