llvm-svn: 143111

rdar://10348844

llvm-svn: 143110

llvm-svn: 143109

rdar://10348584

llvm-svn: 143108

llvm-svn: 143107

This trades one 64 bit div for one 64 bit mul and some arithmetic.

llvm-svn: 143106

llvm-svn: 143105

llvm-svn: 143104

behind a compile failure on 483.xalancbmk.

llvm-svn: 143102

llvm-svn: 143101

AST file more lazy, so that we don't eagerly load that information for
all known identifiers each time a new AST file is loaded. The eager
reloading made some sense in the context of precompiled headers, since
very few identifiers were defined before PCH load time. With modules,
however, a huge amount of code can get parsed before we see an
@import, so laziness becomes important here.

The approach taken to make this information lazy is fairly simple:
when we load a new AST file, we mark all of the existing identifiers
as being out-of-date. Whenever we want to access information that may
come from an AST (e.g., whether the identifier has a macro definition,
or what top-level declarations have that name), we check the
out-of-date bit and, if it's set, ask the AST reader to update the
IdentifierInfo from the AST files. The update is a merge, and we now
take care to merge declarations before/after imports with declarations
from multiple imports.

The results of this optimization are fairly dramatic. On a small
application that brings in 14 non-trivial modules, this takes modules
from being > 3x slower than a "perfect" PCH file down to 30% slower
for a full rebuild. A partial rebuild (where the PCH file or modules
can be re-used) is down to 7% slower. Making the PCH file just a
little imperfect (e.g., adding two smallish modules used by a bunch of
.m files that aren't in the PCH file) tips the scales in favor of the
modules approach, with 24% faster partial rebuilds.

This is just a first step; the lazy scheme could possibly be improved
by adding versioning, so we don't search into modules we already
searched. Moreover, we'll need similar lazy schemes for all of the
other lookup data structures, such as DeclContexts.

llvm-svn: 143100

The code had it backwards, thinking size_t was signed, and using that for "%zd".

Also let the analysis get the types for (u)intmax_t while we are at it.

llvm-svn: 143099

from r143097.

llvm-svn: 143098

llvm-svn: 143097

be found in namespaces.

llvm-svn: 143096

 

llvm-svn: 143095

the compiler should pick this type up automatically.

llvm-svn: 143094

It is not safe to sink an alloca into a stacksave/stackrestore pair, so don't do that. <rdar://problem/10352360>

llvm-svn: 143093

llvm-svn: 143092

Go not generate a new transition by addTransition methods if nothing changed.

llvm-svn: 143091

llvm-svn: 143090

Enqueue the nodes generated as the result of processing a statement
inside the Core Engine. This makes sure ExpEngine does not access
CoreEngine's private members and is more concise.

llvm-svn: 143089

llvm-svn: 143088

llvm-svn: 143087

llvm-svn: 143086

llvm-svn: 143085

llvm-svn: 143084

functions in the Objective-C language runtime
that is set to the selector that is being passed
to the object.

llvm-svn: 143083

decl. in Darwin due to certain projects requirement. 
// rdar://10277579

llvm-svn: 143082

llvm-svn: 143080

up.  Thus, improving the support for compares is goodness because it increases
the number of terminator instructions we can handle.  This creates many more 
opportunities for target specific fast-isel.

llvm-svn: 143079

place.  No functional change intended.

llvm-svn: 143078

llvm-svn: 143077

llvm-svn: 143076

inferior program for the lldb debugger to operate on.  The fixed lldb executable
corresponds to r142902.

Plus some minor modifications to the test benchmark to conform to way bench.py
is meant to be invoked.

llvm-svn: 143075

change.

llvm-svn: 143074

llvm-svn: 143073

SelectBranch.  No functional change intended.

llvm-svn: 143072

llvm-svn: 143071

We were parsing label references to the i12 encoding, which isn't right.
They need to go to the pci variant instead.

More of rdar://10348687

llvm-svn: 143068