This reapplies r207130 with an additional testcase+and a missing check for
AllocaInst that was missing in one location.
Debug info for optimized code: Support variables that are on the stack and
described by DBG_VALUEs during their lifetime.

Previously, when a variable was at a FrameIndex for any part of its
lifetime, this would shadow all other DBG_VALUEs and only a single
fbreg location would be emitted, which in fact is only valid for a small
range and not the entire lexical scope of the variable. The included
dbg-value-const-byref testcase demonstrates this.

This patch fixes this by
Local
- emitting dbg.value intrinsics for allocas that are passed by reference
- dropping all dbg.declares (they are now fully lowered to dbg.values)
SelectionDAG
- renamed constructors for SDDbgValue for better readability.
- fix UserValue::match() to handle indirect values correctly
- not inserting an MMI table entries for dbg.values that describe allocas.
- lowering dbg.values that describe allocas into *indirect* DBG_VALUEs.
CodeGenPrepare
- leaving dbg.values for an alloca were they are (see comment)
Other
- regenerated/updated instcombine.ll testcase and included source

rdar://problem/16679879
http://reviews.llvm.org/D3374

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207165 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "This reapplies r207130 with an additional testcase+and a missing check for"
Typo in testcase.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207166 91177308-0d34-0410-b5e6-96231b3b80d8
Fix quadratic performance during debug compression due to sections x symbols iteration.

When fixing the symbols in each compressed section we were iterating
over all symbols for each compressed section. In extreme cases this
could snowball severely (5min uncompressed -> 35min compressed) due to
iterating over all symbols for each compressed section (large numbers of
compressed sections can be generated by DWARF type units).

To address this, build a map of the symbols in each section ahead of
time, and access that map if a section is being compressed. This brings
compile time for the aforementioned example down to ~6 minutes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207167 91177308-0d34-0410-b5e6-96231b3b80d8
Change llvm-config --ldflags to report ${CMAKE_CXX_LINK_FLAGS}

Should fix PR19526.

When Oscar added this code in the intial CMake build system port, he had
a TODO saying that ${CMAKE_SHARED_LINKER_FLAGS} was probably wrong.  I
agree.  I'm using ${CMAKE_CXX_LINK_FLAGS} to point LLVM at my custom
installation of gcc 4.recent, so that seems more correct.  With this
change, I can build creduce against an installed clang, and it picks up
the write flags from --ldflags.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207171 91177308-0d34-0410-b5e6-96231b3b80d8
ProfileData: Treat missing function counts as malformed

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207172 91177308-0d34-0410-b5e6-96231b3b80d8
Allow vectorization of bit intrinsics in BB Vectorizer.
This patch adds support for vectorization of  bit intrinsics such as bswap,ctpop,ctlz,cttz.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207174 91177308-0d34-0410-b5e6-96231b3b80d8
[C++] Use 'nullptr'. Tools edition.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207176 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Use a std::list for Loops

As pointed out by David Blaikie in code review, a `std::list<T>` is
simpler than a `std::vector<std::unique_ptr<T>>`.  Another option is a
`std::deque<T>` (which allocates in chunks), but I'd like to leave open
the option of inserting in the middle of the sequence for handling
irreducible control flow on the fly.

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207177 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Stop using range-based for to traverse Loops

A follow-up commit will need the actual iterators.

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207178 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Use LoopData directly

Instead of passing around loop headers, pass around `LoopData` directly.

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207179 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Embed Loop hierarchy in LoopData

Continue refactoring to make `LoopData` first-class.  Here I'm making
the `LoopData` hierarchy explicit, instead of bouncing back and forth
with `WorkingData`.  This simplifies the logic and better matches the
`LoopInfo` design.  (Eventually, `LoopInfo` should be restructured so
that it supports this pass, and `LoopData` can be removed.)

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207180 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Encapsulate LoopData::Header

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207181 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Store the header with the members

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207182 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Expose getPackagedNode()

Make `getPackagedNode()` a member function of
`BlockFrequencyInfoImplBase` so that it's available for templated code.

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207183 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: LoopData::MemberList => NodeList

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207184 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Separate unwrapLoops() from finalizeMetrics()

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207185 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Unwrap from Loops

When unwrapping loops, just visit the loops rather than all nodes.

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207186 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Pass the Loop directly into unwrapLoopPackage()

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207187 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: unwrapLoopPackage() => unwrapLoop()

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207188 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Scale LoopData::Scale on the way down

Rather than scaling loop headers and then scaling all the loop members
by the header frequency, scale `LoopData::Scale` itself, and scale the
loop members by it.  It's much more obvious what's going on this way,
and doesn't cost any extra multiplies.

<rdar://problem/14292693>

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