It is sometimes useful to have the C++ standard library linked into the
assembly when compiling clang, particularly when distributing a compiler
onto systems that don't have a copy of stdlibc++ or libc++ installed.

This functionality should work with either GCC or Clang as the host
compiler, though statically linking libc++ (as may be required for
licensing purposes) is only possible if the host compiler is Clang with
a copy of libc++ available.

Differential Revision: https://reviews.llvm.org/D65603

llvm-svn: 368907

llvm-svn: 368906

llvm-svn: 368905

Looks like the problem was due to the cmake cache, Chris fixed in r368897.

llvm-svn: 368902

Once the failure this is testing is fixed, this would fail due to
using too many registers.

llvm-svn: 368901

AllOnes has been split into build-vector-allones.ll.

llvm-svn: 368900

Seems like a copy-paste from couple lines above.

llvm-svn: 368899

We already supported rewriting loop exit values for multiple exit loops, but if any of the loop exits were not computable, we gave up on all loop exit values. This patch generalizes the existing code to handle individual computable loop exits where possible.

As discussed in the review, this is a starting point for figuring out a better API.  The code is a bit ugly, but getting it in lets us test as we go.  

Differential Revision: https://reviews.llvm.org/D65544

llvm-svn: 368898

This cleans up fallout from https://reviews.llvm.org/D66195.

llvm-svn: 368897

Some bots can't find is_final despite it being in C++14. Leave the code as it was for now, fix it later when the bots are happy.

llvm-svn: 368896

I'm planning on handling intrinsics that will benefit from checking
the address space enums. Don't bother moving the address collection
for now, since those won't need th enums.

llvm-svn: 368895

The IR is invalid if this isn't a constant since immarg was added.

llvm-svn: 368893

My last commit fumbled it.

llvm-svn: 368892

Summary: There are places where a case that debug label scope has an extra lexical block file is not considered properly. The modified test won't pass without this patch.

Reviewers: aprantl, HsiangKai

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66187

llvm-svn: 368891

As of D66195 we support C++14 by default.

llvm-svn: 368890

MSVC is weird about __cplusplus. The check I added in D66195 confuses it.

llvm-svn: 368889

llvm-svn: 368888

Summary:
I just bumped the minimum compiler versions to support C++14 in D66188.

Following [our process](http://llvm.org/docs/DeveloperPolicy.html#toolchain) and [our previous agreement](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html), I'm now officially bumping the C++ version to 14 and updating the documentation.

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, chandlerc, thakis, EricWF, jyknight, lhames, JDevlieghere

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66195

llvm-svn: 368887

https://rise4fun.com/Alive/THl

llvm-svn: 368886

Reviewers: jdoerfert, reames

Reviewed By: jdoerfert

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66161

llvm-svn: 368884

After switching over LLDB's line table parser to libDebugInfo, we
noticed two regressions on the Windows bot. The problem is that when
obtaining a file from the line table prologue, we append paths without
specifying a path style. This leads to incorrect results on Windows for
debug info containing Posix paths:

  0x0000000000201000: /tmp\b.c, is_start_of_statement = TRUE

This patch is an attempt to fix that by guessing the path style whenever
possible.

Differential revision: https://reviews.llvm.org/D66227

llvm-svn: 368879

llvm-svn: 368877

Summary: I think this is better solution than annotating callsites in IC/SLC.

Reviewers: jdoerfert

Reviewed By: jdoerfert

Subscribers: MaskRay, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66217

llvm-svn: 368875

Summary:
We can't speculate around indirect branches: indirectbr and invoke. The
callbr instruction needs to be included here.

Reviewers: nickdesaulniers, manojgupta, chandlerc

Reviewed By: chandlerc

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66200

llvm-svn: 368873

llvm-svn: 368870

llvm-svn: 368869

Summary:
Fixes PR42973. Tests don't change because simd-arith.ll tests behavior
on unimplemented-simd128, which does not include any temporary
workarounds such as the one removed in this revision.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, dmgreen, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66166

llvm-svn: 368868

llvm-svn: 368865

Improves the 8 byte case from PR42674.

Differential Revision: https://reviews.llvm.org/D66069

llvm-svn: 368864

It looks like this bracket was added when the addrspace was added.
before it. So I think it can jut be removed.

llvm-svn: 368861

Address one left comment on https://reviews.llvm.org/D63547. A minor
change for assertion.

Differential Revision: https://reviews.llvm.org/D63547

llvm-svn: 368860

build-vector-tests.ll is far too big, split such type tests for single
buildvector into new file.

llvm-svn: 368859

Now that we legalize by widening, the element types here won't change. Previously these were modeled as the elements being widened and then the instruction might become an AND or SHL/ASHR pair. But now they'll become something like a ZERO_EXTEND_VECTOR_INREG/SIGN_EXTEND_VECTOR_INREG.

For AVX2, when the destination type is legal its clear the cost should be 1 since we have extend instructions that can produce 256 bit vectors from less than 128 bit vectors. I'm a little less sure about AVX1 costs, but I think the ones I changed were definitely too high, but they might still be too high.

Differential Revision: https://reviews.llvm.org/D66169

llvm-svn: 368858

llvm-svn: 368857

Rename one to XX3Form_SameOp, remove the other one.

llvm-svn: 368856

Summary:
This patch adds call lowering functionality to enable passing
parameters onto floating point registers when needed.

Differential Revision: https://reviews.llvm.org/D63654

llvm-svn: 368855

This reverts commit r368849, because it breaks some bots (e.g.
llvm-clang-x86_64-win-fast).

It turns out this is not as NFC as we had hoped, because operator== will
consider two std::error_codes to be distinct even though they both hold
"success" values if they have different categories.

llvm-svn: 368854

Summary:
The main motivation for this is unit tests, which contain a large macro
for pretty-printing std::error_code, and this macro is duplicated in
every file that needs to do this. However, the functionality may be
useful elsewhere too.

In this patch I have reimplemented the existing ASSERT_NO_ERROR macros
to reuse the new functionality, but I have kept the macro (as a
one-liner) as it is slightly more readable than ASSERT_EQ(...,
std::error_code()).

Reviewers: sammccall, ilya-biryukov

Subscribers: zturner, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D65643

llvm-svn: 368849

With -phi-node-folding-threshold=3
this branch would get flattened into select.

See https://reviews.llvm.org/D65148#1629010

llvm-svn: 368847

llvm-svn: 368840