exponent_t is only used internally in APFloat and no exponent_t values are
exposed via the APFloat API. In light of such conditions it does not make any
sense to gum up the llvm namespace with said type. Plus it makes it clearer that
exponent_t is associated with APFloat.

llvm-svn: 184686

We now no longer need alias analysis - the cases that alias analysis would
handle are now handled as accesses with a large dependence distance.

We can now vectorize loops with simple constant dependence distances.

  for (i = 8; i < 256; ++i) {
    a[i] = a[i+4] * a[i+8];
  }

  for (i = 8; i < 256; ++i) {
    a[i] = a[i-4] * a[i-8];
  }

We would be able to vectorize about 200 more loops (in many cases the cost model
instructs us no to) in the test suite now. Results on x86-64 are a wash.

I have seen one degradation in ammp. Interestingly, the function in which we
now vectorize a loop is never executed so we probably see some instruction
cache effects. There is a 2% improvement in h264ref. There is one or the other
TSCV loop kernel that speeds up.

radar://13681598

llvm-svn: 184685

This class checks dependences by subtracting two Scalar Evolution access
functions allowing us to catch very simple linear dependences.

The checker assumes source order in determining whether vectorization is safe.
We currently don't reorder accesses.
Positive true dependencies need to be a multiple of VF otherwise we impede
store-load forwarding.

llvm-svn: 184684

Sets of dependent accesses are built by unioning sets based on underlying
objects. This class will be used by the upcoming dependence checker.

llvm-svn: 184683

This renames variable name to reflect initial undefined symbols that are
defined by the linker -u option.

This doesnot change any functionality in lld, and updates code to reflect
Nick's comment.

llvm-svn: 184682

Untill now we detected the vectorizable tree and evaluated the cost of the
entire tree.  With this patch we can decide to trim-out branches of the tree
that are not profitable to vectorizer.

Also, increase the max depth from 6 to 12. In the worse possible case where all
of the code is made of diamond-shaped graph this can bring the cost to 2**10,
but diamonds are not very common.

llvm-svn: 184681

This makes it possible to write unit tests that are less susceptible
to minor code motion, particularly copy placement. block-placement.ll
covers this case with -pre-RA-sched=source which will soon be
default. One incorrectly named block is already fixed, but without
this fix, enabling new coalescing and scheduling would cause more
failures.

llvm-svn: 184680

whether they replace any existing lookups in the context, rather than
accumulating a bunch of lookup results referring to the same entity.

llvm-svn: 184679

follow.

llvm-svn: 184678

llvm-svn: 184677

so that -Wdocumentation-unknown-command does not warn on these commands.
Fixes PR16092.

llvm-svn: 184676

Patch by Robert Wilhelm.

llvm-svn: 184675

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