cleaned up its API slightly.

llvm-svn: 111053

when the CXTranslationUnit_CacheCompletionResults option is given to
clang_parseTranslationUnit(). Essentially, we compute code-completion
results for macro definitions after we have parsed the file, then
store an ASTContext-agnostic version of those results (completion
string, cursor kind, priority, and active contexts) in the
ASTUnit. When performing code completion in that ASTUnit, we splice 
the macro definition results into the results provided by the actual
code-completion (which has had macros turned off) before libclang gets
those results. We use completion context information to only splice in
those results that make sense for that context.

With a completion involving all of the macros from Cocoa.h and a few other
system libraries (totally ~8500 macro definitions) living in a
precompiled header, we get about a 9% performance improvement from
code completion, since we no longer have to deserialize all of the
macro definitions from the precompiled header. 

Note that macro definitions are merely the canary; the cache is
designed to also support other top-level declarations, which should be
a bigger performance win. That optimization will be next.

Note also that there is no mechanism for determining when to throw
away the cache and recompute its contents.

llvm-svn: 111051

llvm-svn: 111050

Also cleaned up its API a tiny bit (but not the
extensive amount that is actually needed.  That's
still coming.)

llvm-svn: 111049

instruction opcode.  This fixes part of PR7792.

llvm-svn: 111047

when they are the same loop. Don't compare two instructions'
loop depths when they are in the same block.

llvm-svn: 111045

Not yet complete or used.

llvm-svn: 111044

When a live range is contained a single block, we can split it around
instruction clusters. The current approach is very primitive, splitting before
and after the largest gap between uses.

llvm-svn: 111043

ScalarEvolution::getAddExpr, which can be pretty expensive, when nothing
has changed, which is pretty common.

llvm-svn: 111042

llvm-svn: 111041

llvm-svn: 111040

rather than testing whether the loop contains the other's header.

llvm-svn: 111039

llvm-svn: 111038

the constant operand on the left, as that's where ScalarEvolution
will end up canonicalizing to.

llvm-svn: 111037

llvm-svn: 111036

llvm-svn: 111035

associated loop. This avoids potentially expensive traversals
of the add recurrence's operands.

llvm-svn: 111034

llvm-svn: 111033

Apparently, this is now fixed in Clang.

llvm-svn: 111032

since they can support trivial implementations. This avoids potentially
expensive traversals of the operands.

llvm-svn: 111031

same lines as the change I made for ARM saturate instructions.

llvm-svn: 111029

misanalysis and is undesirable.

llvm-svn: 111028

-static variables
-variables in anonymous namespace (fixes rdar://7794535)
-static data members in anonymous namespace
-static data members specializations in anonymous namespace

llvm-svn: 111027

-static function declarations
-functions in anonymous namespace
-class methods in anonymous namespace
-class method specializations in anonymous namespace
-function specializations in anonymous namespace

llvm-svn: 111026

Change Sema's UnusedStaticFuncs to UnusedFileScopedDecls to allow also keeping track of unused file scoped variables.

    This is only preparation, currently only static function definitions are tracked, as before.

llvm-svn: 111025

llvm-svn: 111024

(nonfragile-abi2), do not consider 'ivar' access
in class methods. Also, improve on diagnostics.
Radar 8304561.

llvm-svn: 111023

llvm-svn: 111022

llvm-svn: 111021

will apply all fixes even when there were other errors in the file.

llvm-svn: 111020

llvm-svn: 111019

llvm-svn: 111016

llvm-svn: 111013

instantiated with unique-external parameters.

llvm-svn: 111012

llvm-svn: 111011

llvm-svn: 111010

qua templates.  The current fix suppresses the access check entirely
in this case;  to do better, we'd need to be able to say that a
particular lookup result came from a particular injected class name,
which is not easy to do with the current representation of LookupResult.
This is on my known-problems list.

llvm-svn: 111009

llvm-svn: 111008

llvm-svn: 111007

into a PCH/AST file.

llvm-svn: 111006