llvm-vtabledump: A vtable dumper

This tool's job is to dump the vtables inside object files.  It is
currently limited to MS ABI vf- and vb-tables but it will eventually
support Itanium-style v-tables as well.

Differential Revision: http://reviews.llvm.org/D4584

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213903 91177308-0d34-0410-b5e6-96231b3b80d8
Opportunistically fix the builders

A builder complained that it couldn't find llvm-vtabledump, this is
probably because it wasn't a dependency of the 'test' target.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213905 91177308-0d34-0410-b5e6-96231b3b80d8
Add an implementation for llvm-nm’s -print-file-name option (aka -o and -A).

The -print-file-name option in llvm-nm is to precede each symbol
with the object file it came from.  While code for the parsing of this
option and its aliases existed there was no code to implement it.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213906 91177308-0d34-0410-b5e6-96231b3b80d8
Add code coverage mapping data, reader, and writer.

This patch implements the data structures, the reader and
the writers for the new code coverage mapping system. 
The new code coverage mapping system uses the instrumentation
based profiling to provide code coverage analysis.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213909 91177308-0d34-0410-b5e6-96231b3b80d8
Add code coverage mapping data, reader, and writer.

This patch implements the data structures, the reader and
the writers for the new code coverage mapping system. 
The new code coverage mapping system uses the instrumentation
based profiling to provide code coverage analysis.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213910 91177308-0d34-0410-b5e6-96231b3b80d8
[PATCH][PPC64LE] Correct little-endian usage of vmrgh* and vmrgl*.

Because the PowerPC vmrgh* and vmrgl* instructions have a built-in
big-endian bias, it is necessary to swap their inputs in little-endian
mode when using them to implement a vector shuffle.  This was
previously missed in the vector LE implementation.

There was already logic to distinguish between unary and "normal"
vmrg* vector shuffles, so this patch extends that logic to use a third
option:  "swapped" vmrg* vector shuffles that are used for little
endian in place of the "normal" ones.

I've updated the vec-shuffle-le.ll test to check for the expected
register ordering on the generated instructions.

This bug was discovered when testing the LE and ELFv2 patches for
safety if they were backported to 3.4.  A different vectorization
decision was made in 3.4 than on mainline trunk, and that exposed the
problem.  I've verified this fix takes care of that issue.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213915 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Clarify some stackmap shadow optimization code as based on review
feedback from Eric Christopher.

No functional change.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213917 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a warning in CoverageMappingReader.cpp

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213920 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-vtabledump: use a std::map instead of a StringMap for VBTables

StringMap doesn't guarantee any particular iteration order,
this is suboptimal when comparing llvm-vtabledump's output for two
object files.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213921 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Add comments to clarify some non-obvious lines in the stackmap-nops.ll
testcases.

Based on code review from Philip Reames. Thanks Philip!



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213923 91177308-0d34-0410-b5e6-96231b3b80d8
[ARM] In thumb mode, emit directive ".code 16" before file level inline
assembly instructions.

This is necessary to ensure ARM assembler switches to Thumb mode before it
starts assembling the file level inline assembly instructions at the beginning
of a .s file.

<rdar://problem/17757232>



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213924 91177308-0d34-0410-b5e6-96231b3b80d8
[SDAG] Start plumbing an assert into SDValues that we don't form one
with a result number outside the range of results for the node.

I don't know how we managed to not really check this very basic
invariant for so long, but the code is *very* broken at this point.
I have over 270 test failures with the assert enabled. I'm committing it
disabled so that others can join in the cleanup effort and reproduce the
issues. I've also included one of the obvious fixes that I already
found. More fixes to come.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213926 91177308-0d34-0410-b5e6-96231b3b80d8
Store nodes only have 1 result.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213928 91177308-0d34-0410-b5e6-96231b3b80d8
[SDAG] Don't insert the VRBase into a mapping from SDValues when the def
doesn't actually correspond to an SDValue at all. Fixes most of the
remaining asserts on out-of-range SDValue result numbers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213930 91177308-0d34-0410-b5e6-96231b3b80d8
[SDAG] Enable the new assert for out-of-range result numbers in
SDValues, fixing the two bugs left in the regression suite.

The key for both of these was the use a single value type rather than
a VTList which caused an unintentionally single-result merge-value node.
Fix this by getting the appropriate VTList in place.

Doing this exposed that the comments in x86's code abouth how MUL_LOHI
operands are handle is wrong. The bug with the use of out-of-range
result numbers was hiding the bug about the order of operands here (as
best i can tell). There are more places where the code appears to get
this backwards still...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213931 91177308-0d34-0410-b5e6-96231b3b80d8
llvm/test/CodeGen/ARM/inlineasm-global.ll: Avoid specifing source file on llc.

It sometimes confuses FileCheck. Consider the case that path contains 'stmib'. :)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213932 91177308-0d34-0410-b5e6-96231b3b80d8
llvm/test/CodeGen/ARM/inlineasm-global.ll: Add explicit triple to appease targeting *-win32.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213933 91177308-0d34-0410-b5e6-96231b3b80d8
[cmake] Use the external project machinery for libcxxabi so that it can
be disabled in CMake or relocated if desired.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213936 91177308-0d34-0410-b5e6-96231b3b80d8
Run sort_includes.py on the AArch64 backend.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213938 91177308-0d34-0410-b5e6-96231b3b80d8
[ARM] Emit ABI_PCS_R9_use build attribute.

Patch by Ben Foster!

Differential Revision: http://reviews.llvm.org/D4657


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