SLP Vectorizer: Implement a simple CSE optimization for the gather sequences.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184660 91177308-0d34-0410-b5e6-96231b3b80d8
Add MI-Sched support for x86 macro fusion.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184664 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64: fix overzealous NEXTing for Windows testing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184667 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: PR14404: Avoid truncating 64 bit values into 32 bits for ULEB128/SLEB128 generation

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184669 91177308-0d34-0410-b5e6-96231b3b80d8
SLP Vectorizer: Erase instructions outside the vectorizeTree method.
The RAII builder location guard is saving a reference to instructions, so we can't erase instructions during vectorization.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184671 91177308-0d34-0410-b5e6-96231b3b80d8
SLP Vectorizer: Fix a bug in the code that does CSE on the generated gather sequences.
Make sure that we don't replace and RAUW two sequences if one does not dominate the other.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184674 91177308-0d34-0410-b5e6-96231b3b80d8
Fix tail merging to assign the (more) correct BasicBlock when splitting.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184680 91177308-0d34-0410-b5e6-96231b3b80d8
SLP Vectorizer: Add support for vectorizing parts of the tree.

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.




git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184681 91177308-0d34-0410-b5e6-96231b3b80d8
LoopVectorize: Add utility class for building sets of dependent accesses

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184683 91177308-0d34-0410-b5e6-96231b3b80d8
LoopVectorize: Add utility class for checking dependency among accesses

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184684 91177308-0d34-0410-b5e6-96231b3b80d8
LoopVectorize: Use the dependence test utility class

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184685 91177308-0d34-0410-b5e6-96231b3b80d8
[APFloat] Rename llvm::exponent_t => llvm::APFloat::ExponentType.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184686 91177308-0d34-0410-b5e6-96231b3b80d8
[APFloat] Removed out of date comment from isNormal().

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184687 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "LoopVectorize: Use the dependence test utility class"

This reverts commit cbfa1ca993363ca5c4dbf6c913abc957c584cbac.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184690 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: add some testing from an overly broad end-to-end test in Clang

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184692 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: enumerator values returned as int64 as they are stored

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184694 91177308-0d34-0410-b5e6-96231b3b80d8
Filter out dragonegg when checked out into a projects subdirectory.
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184697 91177308-0d34-0410-b5e6-96231b3b80d8
Add a flag to defer vectorization into a phase after the inliner and its
CGSCC pass manager. This should insulate the inlining decisions from the
vectorization decisions, however it may have both compile time and code
size problems so it is just an experimental option right now.

Adding this based on a discussion with Arnold and it seems at least
worth having this flag for us to both run some experiments to see if
this strategy is workable. It may solve some of the regressions seen
with the loop vectorizer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184698 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: enable decoding of pc-relative PLD/PLI

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184701 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: fix IT decoding

mask == 0 -> UNPRED

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184702 91177308-0d34-0410-b5e6-96231b3b80d8