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

llvm-svn: 207154

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

llvm-svn: 207153

after we've already instantiated a definition for the function, pass it to the
ASTConsumer again so that it knows the specialization kind has changed and can
update the function's linkage.

This only matters if we instantiate the definition of the function before we
reach the end of the TU; this can happen in at least three different ways:
C++11 constexpr functions, C++14 deduced return types, and functions
instantiated within modules.

llvm-svn: 207152

llvm-svn: 207151

llvm-svn: 207150

llvm-svn: 207149

values of variables in the Materializer.

The Materializer should not write the variable
back if its new value is the *same* as the old
value, not if the new value is *different*.

<rdar://problem/16712205>

llvm-svn: 207148

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

This patch is to fix a compatibility issue with MSVC link.exe as to
use of dllexported symbols inside DLL.

A DLL exports two symbols for a function. One is non-decorated one,
and the other is with __imp_ prefix. The former is a function that
you can directly call, and the latter is a pointer to the function.
These dllexported symbols are created by linker for programs that
link against the DLL. So, I naturally believed that __imp_ symbols
become available when you once create a DLL and link against it, but
they don't exist until then. And that's not true.

MSVC link.exe is smart enough to allow users to use __imp_ symbols
locally. That is, if a symbol is specified with /export option, it
implicitly creates a new symbol with __imp_ prefix as a pointer to
the exported symbol. This feature allows the following program to
be linked and run, although _imp__hello is not defined in this code.

  #include <stdio.h>

  __declspec(dllexport)
  void hello(void) { printf("Hello\n"); }

  extern void (*_imp__hello)(void);

  int main() {
    _imp__hello();
    return 0;
  }

MSVC link.exe prints out the following warning when linking it.

  LNK4217: locally defined symbol _hello imported in function _main

Using __imp_ symbols locally is I think not a good coding style. One
should just take an address using "&" operator rather than appending
__imp_ prefix. However, there are programs in the wild that depends
on this link.exe's behavior, so we need this feature.

llvm-svn: 207141

llvm-svn: 207140

Fixed an issue where we would try to interrupt a process while it is in the process of naturally stopping due to another reason (breakpoint, or step).

Added a new MachProcess::Interrupt() which correctly tracks such cases and "does the right thing".

<rdar://problem/16593556>

llvm-svn: 207139

llvm-svn: 207138

llvm-svn: 207137

llvm-svn: 207136

of the dbg.value. This gets rid of tons of redundant variable DIEs in
subscopes.

rdar://problem/14874886, rdar://problem/16679936

llvm-svn: 207135