Remove the concepts of "forward" and "general" mass distributions, which
was wrong.  The split might have made sense in an early version of the
algorithm, but it's definitely wrong now.

<rdar://problem/14292693>

llvm-svn: 207195

<rdar://problem/14292693>

llvm-svn: 207194

The branch weights were even before.  Make them different.

<rdar://problem/14292693>

llvm-svn: 207193

Strip irreducible testcases to pure control flow.  The function calls
made the branch weights more believable but cluttered it up a lot.
There isn't going to be any constant analysis here, so just use dumb
branch logic to clarify the important parts.

<rdar://problem/14292693>

llvm-svn: 207192

<rdar://problem/14292693>

llvm-svn: 207191

<rdar://problem/14292693>

llvm-svn: 207190

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>

llvm-svn: 207189

<rdar://problem/14292693>

llvm-svn: 207188

<rdar://problem/14292693>

llvm-svn: 207187

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

<rdar://problem/14292693>

llvm-svn: 207186

<rdar://problem/14292693>

llvm-svn: 207185

<rdar://problem/14292693>

llvm-svn: 207184

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

<rdar://problem/14292693>

llvm-svn: 207183

<rdar://problem/14292693>

llvm-svn: 207182

<rdar://problem/14292693>

llvm-svn: 207181

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>

llvm-svn: 207180

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

<rdar://problem/14292693>

llvm-svn: 207179

A follow-up commit will need the actual iterators.

<rdar://problem/14292693>

llvm-svn: 207178

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>

llvm-svn: 207177

llvm-svn: 207176

This patch adds support for vectorization of  bit intrinsics such as bswap,ctpop,ctlz,cttz.

llvm-svn: 207174

llvm-svn: 207172

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.

llvm-svn: 207171

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.

llvm-svn: 207167

Typo in testcase.

llvm-svn: 207166

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

llvm-svn: 207165

This reverts commit 207130 for buildbot breakage.

llvm-svn: 207162

This reverts commit 207130 for buildbot breakage.

llvm-svn: 207159

llvm-svn: 207158

llvm-svn: 207157

llvm-svn: 207156

[DWARF parser] DWARFUnit ctor doesn't need both parsed and raw .debug_abbrev section. Remove the former.

llvm-svn: 207153

llvm-svn: 207151

condition into an obviously infinite loop with an assert about the
degenerate condition. No functionality changed.

llvm-svn: 207147

Based on review feedback from Dave on the original patch.

llvm-svn: 207146

Should unbreak MultiSource/Benchmarks/mediabench/g721/g721encode/encode.

llvm-svn: 207145

MSVC doesn't diagnose this, interestingly.

llvm-svn: 207144

This is similar to the 'tail' marker, except that it guarantees that
tail call optimization will occur.  It also comes with convervative IR
verification rules that ensure that tail call optimization is possible.

Reviewers: nicholas

Differential Revision: http://llvm-reviews.chandlerc.com/D3240

llvm-svn: 207143

llvm-svn: 207142

llvm-svn: 207136