Now that multiple DAGUpdateListeners can be active at the same time,
ISelPosition can become a local variable in DoInstructionSelection.

We simply register an ISelUpdater with CurDAG while ISelPosition exists.

llvm-svn: 155249

Instead of passing listener pointers to RAUW, let SelectionDAG itself
keep a linked list of interested listeners.

This makes it possible to have multiple listeners active at once, like
RAUWUpdateListener was already doing. It also makes it possible to
register listeners up the call stack without controlling all RAUW calls
below.

DAGUpdateListener uses an RAII pattern to add itself to the SelectionDAG
list of active listeners.

llvm-svn: 155248

llvm-svn: 155247

Per Greg Clayton:
libclang.dylib is trying to be smart and load itself at a valid address
to be able to load faster which would work for 32 bit systems,
bit won't make any difference on 64 bit systems.
It should either pick a better 64 bit address, or just let itself be loaded at zero.

rdar://11159142

llvm-svn: 155246

objc_returns_inner_pointer attribute can be applied to
methods only. Diagnsose otherwise, instead of
crashing. // rdar://11253688

llvm-svn: 155245

This is needed to ensure that we always report issues in the correct
function. For example, leaks are identified when we call remove dead
bindings. In order to make sure we report a callee's leak in the callee,
we have to run the operation in the callee's context.

This change required quite a bit of infrastructure work since:
 - We used to only run remove dead bindings before a given statement;
here we need to run it after the last statement in the function. For
this, we added additional Program Point and special mode in the
SymbolReaper to remove all symbols in context lower than the current
one.
 - The call exit operation turned into a sequence of nodes, which are
now guarded by CallExitBegin and CallExitEnd nodes for clarity and
convenience.

(Sorry for the long diff.)

llvm-svn: 155244

llvm-svn: 155243

llvm-svn: 155242

process any more Values.

llvm-svn: 155241

The <undef> flag on a def operand only applies to partial register
redefinitions. Only print the flag when relevant, and print it as
<def,read-undef> to make it clearer what it means.

llvm-svn: 155239

Make sure the "synchronous breakpoint callbacks" get called before the thread plan logic gets invoked, and if they
ask to continue that should short-circuit the thread plans for that thread.  Also add a bit more explanation for
how this machinery is supposed to work.  
Also pass eExecutionPolicyOnlyWhenNeeded, not eExecutionPolicyAlways when evaluating the expression for breakpoint
conditions.

llvm-svn: 155236

llvm-svn: 155235

llvm-svn: 155234

Added logging so we can see when we are trying to complete a forward type and pull in the world. This is due to a compiler bug we are tracking (<rdar://problem/11291658>) where forward decls to classes and types are not properly scoped in namespaces, which results in the current LLDB looking for a type it will find many times in the accelerator tables, but never match. For example, when debugging with clang we get a forward decl like:

class AnalysisResolver;

And we will look for it everywhere and find many many matches, but the decl context of those matching DIEs is "clang::AnalysisResolver", so we never match anything, yet we pull in waaayyy too much DWARF in the process.

To enable this logging enable the "lookups" category in the "dwarf" log channel:

(lldb) log enable dwarf lookups

llvm-svn: 155233

llvm-svn: 155232

llvm-svn: 155230

llvm-svn: 155229

This nicely handles the most common case of virtual register sets, but
also handles anticipated cases where we will map pointers to IDs.

The goal is not to develop a completely generic SparseSet
template. Instead we want to handle the expected uses within llvm
without any template antics in the client code. I'm adding a bit of
template nastiness here, and some assumption about expected usage in
order to make the client code very clean.

The expected common uses cases I'm designing for:
- integer keys that need to be reindexed, and may map to additional
  data
- densely numbered objects where we want pointer keys because no
  number->object map exists.

llvm-svn: 155227

llvm-svn: 155226

llvm-svn: 155225

overwriting the input file.  For example,

clang -c foo.s -o foo.o -save-temps

Unfortunately, the original patch didn't compare the paths of the input and
output files.  Thus, something like the following would fail to create foo.s.

cd /tmp/obj
clang -c ../src/foo.s -o foo.o -save-temps

rdar://11252615

llvm-svn: 155224

Don't put the address of the module in the module basename as this hoses up our ability to find shared libraries by name. We now put it into the Module object name.

llvm-svn: 155223

build system generate this file with the proper version.

llvm-svn: 155222

build system generate this file with the proper version.

llvm-svn: 155221

non-const reference parameter type if the class had any subobjects with deleted
copy constructors. This causes a rejects-valid if the class's copy constructor
is explicitly defaulted (as happens for some implementations of std::pair etc).

llvm-svn: 155218

Color is still yellow, as 3.1 isn't released yet.

llvm-svn: 155217

* MSVC does not yet support initializer lists and uniform initialization.
* MSVC does not support flexible array members (And neither does C++).

The Mach-O writer test still fails with this, but it all compiles and
all other tests pass.

llvm-svn: 155215

llvm-svn: 155213

llvm-svn: 155211

Use the new TwoOperandAliasConstraint to handle lots of the two-operand aliases
for NEON instructions. There's still more to go, but this is a good chunk of
them.

llvm-svn: 155210

Add debugging hints for when bugpoint does not suffice, specifically for instcombine and TargetLowering

llvm-svn: 155209

 - Also, drop the lines.gif background from doxygen, this URL was wrong on the
   llvm.org server anyway.

llvm-svn: 155208

Add a FIXME comment.
rdar://11283560

llvm-svn: 155207

llvm-svn: 155206

tested.

llvm-svn: 155205

llvm-svn: 155204

llvm-svn: 155203

llvm-svn: 155202

llvm-svn: 155199

already contains the SourceManager.

llvm-svn: 155198