This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially  { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).

I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).

The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.

llvm-svn: 230413

graph with M modules to take O(P) time, not just O(M) time, when using explicit
module builds.

llvm-svn: 230412

This patch unifies the comdat and non-comdat code paths. By doing this
it add missing features to the comdat side and removes the fixed
section assumptions from the non-comdat side.

In ELF there is no one true section for "4 byte mergeable" constants.
We are better off computing the required properties of the section
and asking the context for it.

llvm-svn: 230411

Suggested by Duncan. Happy to bikeshed the name, cache the result, etc.

llvm-svn: 230410

llvm-svn: 230409

If you try to auto-complete "target symbols<TAB>" you get "target symbolsadd" instead of "target symbols ".

Fix this by returning the fact that the "symbols" word is complete if there is nothing else to complete after the "symbols" word.

<rdar://problem/19164599>

llvm-svn: 230408

I'd been using '' where I should have been using ``.

llvm-svn: 230407

It crashes for targeting (i686|x86_64)-win32.

  clang: clang/lib/AST/VTableBuilder.cpp:142: {anonymous}::FinalOverriders::OverriderInfo {anonymous}::FinalOverriders::getOverrider(const clang::CXXMethodDecl*, clang::CharUnits) const: Assertion `OverridersMap.count(std::make_pair(MD, BaseOffset)) && "Did not find overrider!"' failed.

llvm-svn: 230406

Also, fix confusing bit of the gcroot documentation that bit me personally.

llvm-svn: 230405

llvm-svn: 230404

Fixing an issue pointed out by Sean Silva.  Thanks!

llvm-svn: 230403

llvm-svn: 230402

"After recent changes, some code has become redundant. This revision tries to remove
the un-used code and tidy up the rest.

Following 4 files have been removed. I have updated CMake files and checked that it builds
fine on Linux and Windows. Can somebody update the xcode related file accordingly?

tools/lldb-mi/MICmnStreamStdinLinux.cpp
tools/lldb-mi/MICmnStreamStdinLinux.h
tools/lldb-mi/MICmnStreamStdinWindows.cpp
tools/lldb-mi/MICmnStreamStdinWindows.h"

llvm-svn: 230401

was some flexibility in the check line for the comment basic block.

llvm-svn: 230400

It was maintaining two huge file lists that are identical except
for 1 file.  Make this work the proper way.

llvm-svn: 230398

Mostly minor wording changes for readability.  Nothing major to see here.

llvm-svn: 230397

When you use generator expressions in a library sources list,
and then later access the SOURCES property, the OLD behavior
(CMake 3.0 and earlier) would not include these expressions in
the SOURCES property.  The NEW behavior (starting in CMake 3.1)
is that they do include the generator expressions in the SOURCES
property.

Differential Revision: http://reviews.llvm.org/D7870
Reviewed By: Chris Bieneman

llvm-svn: 230396

Commit of patch in http://reviews.llvm.org/D7871

llvm-svn: 230395

The builder is based on a layout algorithm that tries to keep members of
small bit sets together. The new layout compresses Chromium's bit sets to
around 15% of their original size.

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

llvm-svn: 230394

This is still gcroot vs gc.statepoint agnostic.  I'm just trying to clarify the general documentation at this point.

llvm-svn: 230393

There is no need to open-code the alignment calculation, we have a
handy RoundUpToAlignment function which "Does The Right Thing (TM)".

llvm-svn: 230392

llvm-svn: 230391

llvm-svn: 230390

This resubmits r230380.  The primary cause of the failure was
actually just a warning, which we can disable at the CMake level
in a followup patch on the LLVM side.  The other thing which was
actually an error on the bot should be able to be fixed with
a clean.

llvm-svn: 230389

Reapplied D7816 & rL230177 & rL230278 - with an additional fix toensure that the smallest build vector input scalar type is always used. Additional (crash) test cases already committed.

llvm-svn: 230388

Most of the checks in these two tests were actually testing the
behaviour of the instrprof LLVM pass. Now that we're testing that
specifically in LLVM's test suite, it's better if we only test the
frontend's behaviour here.

llvm-svn: 230387

Added test case for PR22678 (check CONCAT_VECTORS DAG combiner pass doesn't introduce illegal types)

llvm-svn: 230386

Commiting code from review http://reviews.llvm.org/D7841

llvm-svn: 230385

wrong (DiagnoseUseOfDecl should take both), but it's more consistent with what
we do in other places.

llvm-svn: 230384

This test checks that the symbols instrprof creates have appropriate
linkage. The tests already exist in clang in a slightly different form
from before we sunk profile generation into an LLVM pass, but that's
an awkward place for them now. I'll remove/simplify the clang versions
shortly.

llvm-svn: 230383

This reverts commit r230380.  It causes CMake to fail on certain
machines with an error about needing to use string(STRIP_GENEX).

llvm-svn: 230382

implicitly construct a temporary in a reference binding.

llvm-svn: 230381

An OBJECT library is a special type of CMake library that produces
no archive, has no link interface, and no link inputs.  It is like
a regular archive, just without the physical output.  To link
against an OBJECT library, you reference it in the *source* file
list of a library using the special syntax $<TARGET_OBJECTS:lldbAPI>.
This will cause every object file to be passed to the linker
independently, as opposed to a single archive being passed to the
linker.

This is *extremely* important on Windows.  lldbAPI exports all of the
SB classes using __declspec(dllexport).  Unfortunately for technical
reasons it is not possible (well, extremely difficult) to get the
linker to propagate a __declspec(dllexport) attribute from a symbol
in an object file in an archive to a DLL that links against that
archive.  The solution to this is for the DLL to link the object files
directly.  So lldbAPI must be an OBJECT library.

This fixes an issue that has been present since the duplicated
lldbAPI file lists were removed, which would cause linker failures.

As a side effect, this also makes LLDB_DISABLE_PYTHON=1 work again
on Windows, which was previously totally broken.

llvm-svn: 230380

This is generating problems when you have built both debug and
release python.  For now I just want to get CMake to work, I
will work on a more robust fix later.  In the meantime you may
need to copy python27(_d).dll manually to ninja\bin after
building.

llvm-svn: 230379

llvm-svn: 230378

constructs is not rejected by should be; that's PR22673.

llvm-svn: 230370

llvm-svn: 230363

Summary: Fixes PR22671.

Reviewers: rsmith

Subscribers: cfe-commits

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

llvm-svn: 230362

llvm-svn: 230361

TODO: The iwmmx register save & restore functions still need the same treatment.
      I didn't do that in this patch because the integrated assembler has a bug
      where it refuses to build them on -march=armv6-m, even with
         .march armv5t
         .arm
      in front of those functions.

This should fix PR22384.

http://reviews.llvm.org/D7258

llvm-svn: 230360