the new ObjC's abi.

llvm-svn: 62721

This avoids call overhead and extraneous switches when parsing
very simple declspecs like "int" "void" etc, which are pretty common :)

llvm-svn: 62711

llvm-svn: 62708

and more idiomatic.

llvm-svn: 62705

llvm-svn: 62704

David Chisnall

llvm-svn: 62703

llvm-svn: 62677

llvm-svn: 62676

tells us whether Preprocessor::HandleIdentifier needs to be called.
Because this method is only rarely needed, this saves a call and a
bunch of random checks.  This drops the time in HandleIdentifier 
from 3.52ms to .98ms on cocoa.h on my machine.

llvm-svn: 62675

llvm-svn: 62674

llvm-svn: 62673

llvm-svn: 62672

llvm-svn: 62671

file, just load them directly as ints.

llvm-svn: 62668

Because the RegionStore can reason about values beyond the reasoning power of BasicStore, this patch splits some of the test cases for the retain/release checker to have versions that are handled by RegionStore (more warnings) and BasicStore (less warnings).

llvm-svn: 62667

llvm-svn: 62666

this removes 4266 calls to LookupDecl.

llvm-svn: 62662

llvm-svn: 62656

Static Analyzer: When generating plists for errors reports, generate one plist file per translation unit that contains all of the diagnostics.

llvm-svn: 62647

No change in functionality.

llvm-svn: 62646

No functionality change.

llvm-svn: 62640

Fix: <rdar://problem/6510344> [pth] PTH slows down regular lexer considerably (when it has substantial work)

Changes to IdentifierTable:
- High-level summary: StringMap never owns IdentifierInfos.  It just
references them.
- The string map now has StringMapEntry<IdentifierInfo*> instead of
  StringMapEntry<IdentifierInfo>.  The IdentifierInfo object is
  allocated using the same bump pointer allocator as used by the
  StringMap.

Changes to IdentifierInfo:
- Added an extra pointer to point to the
  StringMapEntry<IdentifierInfo*> in the string map.  This pointer
  will be null if the IdentifierInfo* is *only* used by the PTHLexer
  (that is it isn't in the StringMap).

Algorithmic changes:
- Non-PTH case:
   IdentifierInfo::get() will always consult the StringMap first to
   see if we have an IdentifierInfo object.  If that StringMapEntry
   references a null pointer, we allocate a new one from the BumpPtrAllocator
   and update the reference in the StringMapEntry.
- PTH case:
   We do the same lookup as with the non-PTH case, but if we don't get
   a hit in the StringMap we do a secondary lookup in the PTHManager for
   the IdentifierInfo.  If we don't find an IdentifierInfo we create a
   new one as in the non-PTH case.  If we do find and IdentifierInfo
   in the PTHManager, we update the StringMapEntry to refer to it so
   that the IdentifierInfo will be found on the next StringMap lookup.
   This way we only do a binary search in the PTH file at most once
   for a given IdentifierInfo.  This greatly speeds things up for source
   files containing a non-trivial amount of code.

Performance impact:
   While these changes do add some extra indirection in
   IdentifierTable to access an IdentifierInfo*, I saw speedups even
   in the non-PTH case as well.

   Non-PTH: For -fsyntax-only on Cocoa.h, we see a 6% speedup.
   PTH (with Cocoa.h in token cache): 11% speedup.

   I also did an experiment where we did -fsyntax-only on a source file
   including a large header and Cocoa.h, but the token cache did not
   contain the larger header.  For this file, we were seeing a performance
   *regression* when using PTH of 3% over non-PTH.  Now we are seeing
   a performance improvement of 9%!

Tests:
   The serialization tests are now failing.  I looked at this extensively,
   and I my belief is that this change is unmasking a bug rather than
   introducing a new one.  I have disabled the serialization tests for now.

llvm-svn: 62636

This allows more concise syntax when allocating an object using the ASTContext's allocator.
Convert a few allocations to this operator to for test purposes.

llvm-svn: 62623

llvm-svn: 62620

caused by my previous commit.

llvm-svn: 62613

When using a BumpPtrAllocator, this reduces malloc overhead from 2.2->1.9% (for Cocoa.h).

At this point, malloc() has dropped the fourth most expensive routine (behind Preprocessor::HandleIdentifier()).

llvm-svn: 62612

llvm-svn: 62611

llvm-svn: 62609

case.

llvm-svn: 62607

Add debug hook to DeclContext.

llvm-svn: 62605

llvm-svn: 62601

function DeclaratorChunk in common cases.  This uses a fixed array in 
Declarator when it is small enough for the first function declarator chunk
in a declarator.

This eliminates all malloc/free traffic from DeclaratorChunk::getFunction
when running on Cocoa.h except for five functions: signal/bsd_signal/sigset,
which have multiple Function DeclChunk's, and 
CFUUIDCreateWithBytes/CFUUIDGetConstantUUIDWithBytes, which take more than
16 arguments.

This patch was pair programmed with Steve.

llvm-svn: 62599

struct.

llvm-svn: 62585

va_list is a struct, like x86-64.

If anyone has a better idea for how to do the check in the if 
statements, suggestions are welcome.

llvm-svn: 62582

Rename DeclContext::insert to DeclContext::makeDeclVisibleInContext and document both it and DeclContext::addDecl properly

llvm-svn: 62581

builtins.

Also, a minor tweak to va_copy for consistency.

llvm-svn: 62574

Remove the TopLevelDecls from TranslationUnit, since all of those decls are owned by the ASTContext's TranslationUnitDecl. There are definitely some leaking Decls now that I'll tackle tomorrow

llvm-svn: 62568

that every declaration lives inside a DeclContext.

Moved several things that don't have names but were ScopedDecls (and,
therefore, NamedDecls) to inherit from Decl rather than NamedDecl,
including ObjCImplementationDecl and LinkageSpecDecl. Now, we don't
store empty DeclarationNames for these things, nor do we try to insert
them into DeclContext's lookup structure.

The serialization tests are temporarily disabled. We'll re-enable them
once we've sorted out the remaining ownership/serialiazation issues
between DeclContexts and TranslationUnion, DeclGroups, etc.

llvm-svn: 62562

llvm-svn: 62556

Dead stores checker: Fix <rdar://problem/6506065> by being more selective when say that a store is dead even though the computed value is used in the enclosing expression.

llvm-svn: 62552