Make sure that we don't replace and RAUW two sequences if one does not dominate the other.

llvm-svn: 184674

llvm-svn: 184673

I'd no sooner made the last commit when Matthew Dempsky sent me another test case that led me to yet another closely related test case that the current design could not handle.  I've now changed the way forward references are handled completely.  It wasn't that much code to change.  The demangler, when confronted with a forward reference to a template parameter, now parses things twice.  During the second parse, all forward references are remembered from the first parse.  Test suite updated with new case.

llvm-svn: 184672

The RAII builder location guard is saving a reference to instructions, so we can't erase instructions during vectorization.

llvm-svn: 184671

llvm-svn: 184669

After a private conversation with Arthur O'Dwyer, and a good night's sleep, I believe this fix is a better fix than what I committed in r184656 yesterday.  I've basically moved the checking for '`' from the start of the demangling process to the end of it.  In the process I discovered that one of the test cases no longer demangled to the expected string.  After further investigation I believe this case to not be a valid mangled string, and so I moved the test case to the 'invalid cases'.  The reason I believe it is invalid is that it should use T_ instead of T0_ to index the template parameter.

llvm-svn: 184668

llvm-svn: 184667

when specifying --coverage (or related) flags.

The system for doing this was based on the old LLVM-hosted profile_rt
library, and hadn't been updated for Linux to use the new compiler-rt
library. Also, it couldn't possibly work on multiarch or biarch systems
in many cases. The whole thing now works much the same as the sanitizer
libraries that are built and used out of the compiler-rt repo.

Note that other target OSes haven't been updated because I don't know if
they're doing anything special with the installation path of profile_rt.
I suspect however that *all* of these are wrong and would encourage
maintainers of each target to take a hard look at how compiler-rt
runtime libraries are linked on their platforms.

llvm-svn: 184666

to build and one had grown out of sync. Put this list in a variable so
this doesn't happen again.

The whole thing here is somewhat suspicious as we don't support 32-bit
environments with a 64-bit bi-arch capable compiler, but none have
complained yet about this so I'm just leaving it alone.

llvm-svn: 184665

This is an awful implementation of the target hook. But we don't have
abstractions yet for common machine ops, and I don't see any quick way
to make it table-driven.

llvm-svn: 184664

llvm-svn: 184663

verifies that we run the assembler and linker in the correct mode, and
that we can successfully use a bi-arch variant of a GCC installation in
a generic cross compilation invocation of Clang.

llvm-svn: 184662

llvm-svn: 184661

llvm-svn: 184660

llvm-svn: 184659

llvm-svn: 184658

Allow the comments in the FriendObjectKind enumerator-list show up in
doxygen. Also, some small readability improvements in related functions.

llvm-svn: 184657

llvm-svn: 184656

llvm-svn: 184655

llvm-svn: 184653

Remove unneeded member in CommentSema, add a test for the XML schema (the
schema already allowed multiple paragraphs in <ResultDiscussion>, but there
were no tests for that), fix HTML generation (it is not allowed to have <p>
inside <dl>).

llvm-svn: 184652

llvm-svn: 184651

Patch by Ismail Pazarbasi!

llvm-svn: 184650

llvm-svn: 184649

llvm-svn: 184648

Rewrote the SLP-vectorization as a whole-function vectorization pass. It is now able to vectorize chains across multiple basic blocks.
It still does not vectorize PHIs, but this should be easy to do now that we scan the entire function.
I removed the support for extracting values from trees.
We are now able to vectorize more programs, but there are some serious regressions in many workloads (such as flops-6 and mandel-2).

llvm-svn: 184647

llvm-svn: 184645

llvm-svn: 184644

llvm-svn: 184643

llvm-svn: 184642

It doesn't work as I intended it to.  This reverts commit r184638.

llvm-svn: 184641

llvm-svn: 184640

llvm-svn: 184639

It has become an expensive operation. No functionality change.

llvm-svn: 184638

Implement full support for non-pointer types in custom allocators.  This is for the unordered containers only.  This work still needs to be done on the sequence containers.

llvm-svn: 184635

Instantiation bug fix extension (cf. r184503) -- minor code fixes, including a typo that caused a runtime assertion after firing diagnosis for class definitions, with the 'template' keyword as template header, in friend declarations.

llvm-svn: 184634

Should bring the ppc64 buildbot back to life.

llvm-svn: 184633

There are fundamentally two different things that were getting conflated
here.

1) A bi-arch GCC toolchain install. This is not a full blown cross
   compiler, but it supports targetting both 32-bit and 64-bit variants
   of the same architecture using multilib OS installs and runtimes.

2) A "multiarch" Debian OS/runtime layout that lays out the libraries,
   headers, etc as-if there were going to be a full blown cross compiler
   even when in reality it is just a bi-arch GCC targeting two variants.
   Also, these tend to use oddly "canonicalized" triples without the
   vendor in them unlike the typical cross compiler runtime library
   search that vanilla GCC cross compilers perform.

Now, when we mean the bi-arch nature of GCC accomplished with just
a suffix or tweak to the GCC paths, we say 'Biarch' or something
related. When we mean the Debian layout of includes and libraries, we
say multiarch or reference the multiarch triple.

In the process of reading and often renaming stuff in all these places,
also reformat with clang-format. No functionality change should be going
on here, this is just tidying up.

llvm-svn: 184632

The problem with r183462 was that we assumed that a diagnostic id of
zero would be silent.

This small correction to CheckDerivedToBaseConversion changes it's
behavior to omit the diagnostic when given a diagnostic id of zero.

This fix passes the test case added in r184402.

llvm-svn: 184631

Removes the last use of PathV1.h in llvm-ar.

llvm-svn: 184630