There is some hope of eventually supporting a unified build with it, but
until then this lets me (and others) check it out in this location
without things breaking.

llvm-svn: 184697

constructing a lookup table.

Previously, buildLookup would add lookup table entries for each item lexically
within the DC, and adding the first entry with a given name would trigger the
external source to add all its entries with that name. Then buildLookup would
carry on and re-add those entries all over again.

Instead, follow a simple rule: a declaration from an external source is only
ever made visible by the external source. One exception to this: since we don't
usually build a lookup table for the TU in C, and we never serialize one, we
don't expect the external source to provide lookups in the TU in C, so we build
those ones ourselves.

llvm-svn: 184696

There's still a problem here - since we're not appropriately using the
signedness/range of the enum to chooset the encoding and emission of
enumerators, but GCC has some bugs around this too so I assume that's
not /such/ a high priority though I may get to it soon out of
completeness.

llvm-svn: 184695

llvm-svn: 184694

The assembly generation testing has been moved to an LLVM test case.

llvm-svn: 184693

llvm-svn: 184692

llvm-svn: 184691

This reverts commit cbfa1ca993363ca5c4dbf6c913abc957c584cbac.

We are seeing a stage2 and stage3 miscompare on some dragonegg bots.

llvm-svn: 184690

llvm-svn: 184689

Original patch by Fariborz Jahanian; extended by me.

Fixes rdar://14124644

llvm-svn: 184688

I already finished the isIEEENormal => isNormal transition. So isNormal is now
IEEE-754R compliant.

llvm-svn: 184687

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