DebugInfo: Split DebugLocEntry into its own file.

It seems big enough that it deserves its own file - but it is header
only, so there's no need for another cpp file, etc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205360 91177308-0d34-0410-b5e6-96231b3b80d8
Add inequality operator for MachineLocation.

Fixes the build I broke in r205360

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205361 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor out the comparison of the location/value in a DebugLocEntry

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205364 91177308-0d34-0410-b5e6-96231b3b80d8
Remove unused function DebugLocEntry::isEmpty

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205365 91177308-0d34-0410-b5e6-96231b3b80d8
Fix accidental fallthrough in DebugLocEntry::hasSameValueOrLocation

No test case (this would invoke UB by examining uninitialized members,
etc, at best - and this code is apparently untested anyway - I'm about
to fix that)

Code review feedback from Adrian Prantl on r205360.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205367 91177308-0d34-0410-b5e6-96231b3b80d8
DebugLocEntry: Actually merge the loc entry when returning true.

Seems we didn't have any test coverage for merging... awesome. So I
added some - but hit an llvm-objdump bug while I was there. I'm choosing
not to shave that yak right now.

Code review feedback/bug catch by Adrian Prantl in r205360.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205373 91177308-0d34-0410-b5e6-96231b3b80d8
Add a doxygen comment to DebugLocEntry::Merge.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205374 91177308-0d34-0410-b5e6-96231b3b80d8
[ARM64][CollectLOH] Add some comments to explain how the LOHs
framework works (for the compiler part), since the design
document is not available.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205379 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Introduce DebugLocList to encapsulate a list of DebugLocEntries and an MC Label to refer to them

This removes the magic-number-esque code creating/retrieving the same
label for a debug_loc entry from two places and removes the last small
piece of reusable logic from emitDebugLoc so that there will be less
duplication when refactoring it into two functions (one for debug_loc,
the other for debug_loc.dwo).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205382 91177308-0d34-0410-b5e6-96231b3b80d8
Split debug_loc and debug_loc.dwo emission into two separate functions

Based on code review feedback from Eric Christopher on r204697

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205385 91177308-0d34-0410-b5e6-96231b3b80d8
Adjust comments regarding non-relocated abbrev offset in debug_info.dwo

I'm not sure the comment in the implementation really adds a lot of
value (it's clear that we emit zero when no symbol is provided, but it
doesn't explain why we would do that). Happy to iterate.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205386 91177308-0d34-0410-b5e6-96231b3b80d8
[LoopVectorizer] Count dependencies of consecutive pointers as uniforms

For the purpose of calculating the cost of the loop at various vectorization
factors, we need to count dependencies of consecutive pointers as uniforms
(which means that the VF = 1 cost is used for all overall VF values).

For example, the TSVC benchmark function s173 has:
  ...
  %3 = add nsw i64 %indvars.iv, 16000
  %arrayidx8 = getelementptr inbounds %struct.GlobalData* @global_data, i64 0, i32 0, i64 %3
  ...
and we must realize that the add will be a scalar in order to correctly deduce
it to be profitable to vectorize this on PowerPC with VSX enabled. In fact, all
dependencies of a consecutive pointer must be a scalar (uniform), and so we
simply need to add all consecutive pointers to the worklist that currently
detects collects uniforms.

Fixes PR19296.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205387 91177308-0d34-0410-b5e6-96231b3b80d8
Added isTargetWindowsMSVC(), renamed isTargetMingw() to isTargetWindowsGNU()
and isTargetCygwin() to isTargetWindowsCygwin() to be consistent with the
four Windows environments in Triple.h.

Suggestion by Saleem Abdulrasool!



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205393 91177308-0d34-0410-b5e6-96231b3b80d8
Remove duplicated DMB instructions

ARM specific optimiztion, finding places in ARM machine code where 2 dmbs
follow one another, and eliminating one of them.

Patch by Reinoud Elhorst.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205409 91177308-0d34-0410-b5e6-96231b3b80d8
Work around gold bug http://sourceware.org/PR16794.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205416 91177308-0d34-0410-b5e6-96231b3b80d8
Mark FPB as a reserved register when needed.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205421 91177308-0d34-0410-b5e6-96231b3b80d8
ARM64: convert fp16 narrowing ISel to pseudo-instruction

The previous attempt was fine with optimisations, but was actually rather
cavalier with its types. When compiled at -O0, it produced invalid COPY
MachineInstrs.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205422 91177308-0d34-0410-b5e6-96231b3b80d8
ARM64: make sure first argument to INSERT_SUBVECTOR has right type.

Again, coalescing and other optimisations swiftly made the MachineInstrs
consistent again, but when compiled at -O0 a bad INSERT_SUBREGISTER was
produced.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205423 91177308-0d34-0410-b5e6-96231b3b80d8
SLPVectorizer: compare entire intrinsic for SLP compatibility.

Some Intrinsics are overloaded to the extent that return type equality (all
that's been checked up to now) does not guarantee that the arguments are the
same. In these cases SLP vectorizer should not recurse into the operands, which
can be achieved by comparing them as "Function *" rather than simply the ID.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205424 91177308-0d34-0410-b5e6-96231b3b80d8
ARM64: fix lowering of fp128 fptosi/fptoui

We were creating libcall nodes that returned an MVT::f128, when these
particular operations actually return an int of some stripe.

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