found with a smarter version of -Wunused-member-function that I'm playwing with.
Appologies in advance if I removed someone's WIP code.

 include/llvm/CodeGen/MachineSSAUpdater.h            |    1 
 include/llvm/IR/DebugInfo.h                         |    3 
 lib/CodeGen/MachineSSAUpdater.cpp                   |   10 --
 lib/CodeGen/PostRASchedulerList.cpp                 |    1 
 lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp    |   10 --
 lib/IR/DebugInfo.cpp                                |   12 --
 lib/MC/MCAsmStreamer.cpp                            |    2 
 lib/Support/YAMLParser.cpp                          |   39 ---------
 lib/TableGen/TGParser.cpp                           |   16 ---
 lib/TableGen/TGParser.h                             |    1 
 lib/Target/AArch64/AArch64TargetTransformInfo.cpp   |    9 --
 lib/Target/ARM/ARMCodeEmitter.cpp                   |   12 --
 lib/Target/ARM/ARMFastISel.cpp                      |   84 --------------------
 lib/Target/Mips/MipsCodeEmitter.cpp                 |   11 --
 lib/Target/Mips/MipsConstantIslandPass.cpp          |   12 --
 lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp              |   21 -----
 lib/Target/NVPTX/NVPTXISelDAGToDAG.h                |    2 
 lib/Target/PowerPC/PPCFastISel.cpp                  |    1 
 lib/Transforms/Instrumentation/AddressSanitizer.cpp |    2 
 lib/Transforms/Instrumentation/BoundsChecking.cpp   |    2 
 lib/Transforms/Instrumentation/MemorySanitizer.cpp  |    1 
 lib/Transforms/Scalar/LoopIdiomRecognize.cpp        |    8 -
 lib/Transforms/Scalar/SCCP.cpp                      |    1 
 utils/TableGen/CodeEmitterGen.cpp                   |    2 
 24 files changed, 2 insertions(+), 261 deletions(-)

llvm-svn: 204560

When VSX is available, these instructions should be used in preference to the
older variants that only have access to the scalar floating-point registers.

llvm-svn: 204559

benchmarks.

<rdar://problem/16368461>

llvm-svn: 204558

Since the profile can come from 32-bit machines, we need to check the
pointer size.  Change the magic number to facilitate this.

Adds tests for reading 32-bit and 64-bit binaries (both big- and
little-endian).  The tests write a binary using printf in RUN lines
(like raw-magic-but-no-header.test).  Assuming the bots don't complain,
this seems like a better way forward for testing RawInstrProfReader than
committing binary files.

<rdar://problem/16400648>

llvm-svn: 204557

Since the profile can come from 32-bit machines, the reader needs to
check the pointer size.  Change the magic number to facilitate this.

<rdar://problem/16400648>

llvm-svn: 204556

This is similar, but not identical to what gas does. The logic in MC is to just
compute the symbol table after parsing the entire file. GAS is mixed, given

.type b, @object
a = b
b:
.type b, @function

It will propagate the change and make 'a' a function. Given

.type b, @object
b:
a = b
.type b, @function

the type of 'a' is still object.

Since we do the computation in the end, we produce a function in both cases.

llvm-svn: 204555

out a visible update record for that namespace even if it was never declared in
this module.

llvm-svn: 204554

llvm-svn: 204553

llvm-svn: 204552

llvm-svn: 204551

llvm-svn: 204550

Some text shows up on stderr when using guard malloc, and this test
was trying to treat that as input to llvm-profdata show. There's no
reason to pipe stderr into show at all here.

llvm-svn: 204549

llvm-svn: 204548

specialization from a module. (This can also happen for function template
specializations in PCHs if they're instantiated eagerly, because they're
constexpr or have a deduced return type.)

llvm-svn: 204547

No functionnal change.

llvm-svn: 204545

When a label is parsed, check if there is type information available for the
label.  If so, check if the symbol is a function.  If the symbol is a function
and we are in thumb mode and no explicit thumb_func has been emitted, adjust the
symbol data to indicate that the function definition is a thumb function.

The application of this inferencing is improved value handling in the object
file (the required thumb bit is set on symbols which are thumb functions).  It
also helps improve compatibility with binutils.

The one complication that arises from this handling is the MCAsmStreamer.  The
default implementation of getOrCreateSymbolData in MCStreamer does not support
tracking the symbol data.  In order to support the semantics of thumb functions,
track symbol data in assembly streamer.  Although O(n) in number of labels in
the TU, this is already done in various other streamers and as such the memory
overhead is not a practical concern in this scenario.

llvm-svn: 204544

v2f64 values, like other 128-bit values, are returned under VSX in register
vs34 (Altivec register v2).

llvm-svn: 204543

When an instruction's operand list does not have a sufficient number of
operands to match with all of the variables that contribute to its
encoding, instead of asserting inside a call to getSubOperandNumber, produce an
informative error.

llvm-svn: 204542

llvm-svn: 204541

FIXME: line_iterator should be tolerant of CR.
llvm-svn: 204540

It was incompatible to standlalone clang build.

llvm-svn: 204539

The cleanup code that removes dead cast instructions only removed them from the
basic block, but didn't delete them. This fix erases them now too.

llvm-svn: 204538

A PHI node usually has only one value/basic block pair per incoming basic block.
In the case of a switch statement it is possible that a following PHI node may
have more than one such pair per incoming basic block. E.g.:
%0 = phi i64 [ 123456, %case2 ], [ 654321, %Entry ], [ 654321, %Entry ]
This is valid and the verfier doesn't complain, because both values are the
same.

Constant hoisting materializes the constant for each operand separately and the
value is still the same, but the variable names have changed. As a result the
verfier can't recognize anymore that they are the same value and complains.

This fix adds special update code for PHI node in constant hoisting to prevent
this corner case.

This fixes <rdar://problem/16394449>

llvm-svn: 204537

[DAG] Fix an assertion failure caused by an invalid cast in method 'BuildVectorSDNode::isConstantSplat'

This patch renames method 'isConstantSplat' as 'getConstantSplatValue'
(mainly for consistency reasons), and rewrites its logic to ensure
that we always perform a legal 'cast<ConstantSDNode>'.

Added test shift-combine-crash.ll to verify that DAGCombiner no longer crashes with an assertion failure in the attempt to simplify a vector shift by a vector of all undef counts.

llvm-svn: 204536

Refactor: move loading pending instantiations from chained PCHs to a more appropriate place, so that we only ask the external source once.

llvm-svn: 204535

even though the underlying exception is a trace exception.

<rdar://problem/15243355>

llvm-svn: 204534

llvm-svn: 204533

llvm-svn: 204531

llvm-svn: 204530

No functional change. This will cleanup a bunch of scan-build warnings.

llvm-svn: 204529

an ID, so this is a noop.
Thanks Manman for catching this!

llvm-svn: 204528

sym_a:
sym_d = sym_a + 1

This is the smallest fix I was able to extract from what got reverted in
r204203.

llvm-svn: 204527

llvm-svn: 204526

performing typo correction on very short (1 or 2 char) identifiers.

llvm-svn: 204525

llvm-svn: 204524

llvm-svn: 204523

We make sure a spill is not hoisted to a hotter outer loop by adding
a condition. Hoist a spill to outer loop if there are multiple dependents
(it can be beneficial if more than one dependents are hoisted) or
if DepSV (the hoisting source) is hotter than SV (the hoisting destination).

rdar://16268194

llvm-svn: 204522

This is a bit of a stab in the dark as I'm not sure I've got these
source files compiling correctly locally. (and the warning only
reproduces on a 32bit build anyway)

llvm-svn: 204521

[Support] Follow up to r204426, for LockFileManager, make the given path absolute so relative paths are properly handled in both Windows and Unix.

llvm-svn: 204520

llvm-svn: 204519