BitcodeReader: Change mechanics of BlockAddress forward references, NFC

Now that we can reliably handle forward references to `BlockAddress`
(r214563), change the mechanics to simplify predicting use-list order.

Previously, we created dummy `GlobalVariable`s to represent block
addresses.  After every function was materialized, we'd go through any
forward references to its blocks and RAUW them with a proper
`BlockAddress` constant.  This causes some (potentially a lot of)
unnecessary use-list churn, since any constant expression that it's a
part of will need to be rematerialized as well.

Instead, pre-construct a `BasicBlock` immediately -- without attaching
it to its (empty) `Function` -- and use that to construct a
`BlockAddress`.  This constant will not have to be regenerated.  When
the function body is parsed, hook this pre-constructed basic block up
in the right place using `BasicBlock::insertInto()`.

Both before and after this change, the IR is temporarily in an invalid
state that gets resolved when `materializeForwardReferencedFunctions()`
gets called.

This is a prep commit that's part of PR5680, but the only functionality
change is the reduction of churn in the constant pool.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214570 91177308-0d34-0410-b5e6-96231b3b80d8
MS inline asm: Hide symbol to attempt to fix test failure on darwin

If the symbol comes from an external DSO, it apparently requires
indirection through a register.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214571 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "R600: Move code for generating REGISTER_LOAD into R600ISelLowering.cpp"

This reverts commit r214566.

I did not mean to commit this yet.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214572 91177308-0d34-0410-b5e6-96231b3b80d8
[SDAG] MorphNodeTo recursively deletes dead operands of the old
fromulation of the node, which isn't really the desired behavior from
within the combiner or legalizer, but is necessary within ISel. I've
added a hopefully helpful comment and fixed the only two places where
this took place.

Yet another step toward the combiner and legalizer not needing to use
update listeners with virtual calls to manage the worklists behind
legalization and combining.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214574 91177308-0d34-0410-b5e6-96231b3b80d8
Debug info: Infrastructure to support debug locations for fragmented
variables (for example, by-value struct arguments passed in registers, or
large integer values split across several smaller registers).
On the IR level, this adds a new type of complex address operation OpPiece
to DIVariable that describes size and offset of a variable fragment.
On the DWARF emitter level, all pieces describing the same variable are
collected, sorted and emitted as DWARF expressions using the DW_OP_piece
and DW_OP_bit_piece operators.

http://reviews.llvm.org/D3373
rdar://problem/15928306

What this patch doesn't do / Future work:
- This patch only adds the backend machinery to make this work, patches
  that change SROA and SelectionDAG's type legalizer to actually create
  such debug info will follow. (http://reviews.llvm.org/D2680)
- Making the DIVariable complex expressions into an argument of dbg.value
  will reduce the memory footprint of the debug metadata.
- The sorting/uniquing of pieces should be moved into DebugLocEntry,
  to facilitate the merging of multi-piece entries.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214576 91177308-0d34-0410-b5e6-96231b3b80d8
llvm/test/CodeGen/Mips/cconv/arguments-varargs.ll: Add explicit -mtriple=(mips|mipsel)-linux on 4 lines.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214578 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Simplify X87 stackifier pass.

Stop using ST registers for function returns and inline-asm instructions and use
FP registers instead. This allows removing a large amount of code in the
stackifier pass that was needed to track register liveness and handle copies
between ST and FP registers and function calls returning floating point values.

It also fixes a bug which manifests when an ST register defined by an
inline-asm instruction was live across another inline-asm instruction, as shown
in the following sequence of machine instructions:

1. INLINEASM <es:frndint> $0:[regdef], %ST0<imp-def,tied5>
2. INLINEASM <es:fldcw $0>
3. %FP0<def> = COPY %ST0

<rdar://problem/16952634>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214580 91177308-0d34-0410-b5e6-96231b3b80d8
UseListOrder: Fix blockaddress use-list order

`parseBitcodeFile()` uses the generic `getLazyBitcodeFile()` function as
a helper.  Since `parseBitcodeFile()` isn't actually lazy -- it calls
`MaterializeAllPermanently()` -- bypass the unnecessary call to
`materializeForwardReferencedFunctions()` by extracting out a common
helper function.  This removes the last of the use-list churn caused by
blockaddresses.

This highlights that we can't reproduce use-list order of globals and
constants when parsing lazily -- but that's necessarily out of scope.
When we're parsing lazily, we never have all the functions in memory, so
the use-lists of globals (and constants that reference globals) are
always incomplete.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214581 91177308-0d34-0410-b5e6-96231b3b80d8
UseListOrder: Guarantee that shuffles change use-list order

Change shuffleUseLists() always to change use-list order by rejecting
orders that have no changes.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214584 91177308-0d34-0410-b5e6-96231b3b80d8
InstrProf: Allow multiple functions with the same name

This updates the instrumentation based profiling format so that when
we have multiple functions with the same name (but different function
hashes) we keep all of them instead of rejecting the later ones.

There are a number of scenarios where this can come up where it's more
useful to keep multiple function profiles:

* Name collisions in unrelated libraries that are profiled together.
* Multiple "main" functions from multiple tools built against a common
  library.
* Combining profiles from different build configurations (ie, asserts
  and no-asserts)

The profile format now stores the number of counters between the hash
and the counts themselves, so that multiple sets of counts can be
stored. Since this is backwards incompatible, I've bumped the format
version and added some trivial logic to skip this when reading the old
format.

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