<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 option is to override the default import file path.

llvm-svn: 207175

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

llvm-svn: 207174

Expose the enum CX_CXXAccessSpecifier in the python bindings as a property of
the cursor.  If access specifier is not applicable to the node, return the
INVALID specifier rather than raising an exception.

Patch by Tamás Szeli!

llvm-svn: 207173

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

llvm-svn: 207170

llvm-svn: 207169

llvm-svn: 207168

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

Currently if you run _any_ python, python has the "lldb.debugger" global variable and it has a strong reference to a lldb_private::Debugger since it is a lldb::SBDebugger object with a shared pointer.

This makes sure that your LLDB command interpreter history is saved each time you quit command line LLDB.

llvm-svn: 207164

Make sure the timeout is set to 0.5s for these.
<rdar://problem/16719510> 

llvm-svn: 207163

This reverts commit 207130 for buildbot breakage.

llvm-svn: 207162

llvm-svn: 207161

currently associated with a given thread, on relevant targets.

Change the queue detection code to verify that the queues 
associated with all live threads are included in the list.
<rdar://problem/16411314> 

llvm-svn: 207160

This reverts commit 207130 for buildbot breakage.

llvm-svn: 207159

llvm-svn: 207158

llvm-svn: 207157

llvm-svn: 207156

llvm-svn: 207155