|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| ... |  | 
| | 
| 
| 
| 
| 
| | can be used to report issues such as a missing PTH file.
llvm-svn: 63231 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | .def file for each library.  This means that adding a diagnostic
to sema doesn't require all the other libraries to be rebuilt.
Patch by Anders Johnsen!
llvm-svn: 63111 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | as reported to the user and as manipulated by #line.  This is what __FILE__,
__INCLUDE_LEVEL__, diagnostics and other things should follow (but not 
dependency generation!).  
This patch also includes several cleanups along the way: 
- SourceLocation now has a dump method, and several other places 
  that did similar things now use it.
- I cleaned up some code in AnalysisConsumer, but it should probably be
  simplified further now that NamedDecl is better.
- TextDiagnosticPrinter is now simplified and cleaned up a bit.
This patch is a prerequisite for #line, but does not actually provide 
any #line functionality.
llvm-svn: 63098 | 
| | 
| 
| 
| | llvm-svn: 63094 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | spelling data in the PTH file.  This removes a ton of code for looking up spellings using sourcelocations in the PTH file.  This simplifies both PTH-generation and reading.
Performance impact for -fsyntax-only on Cocoa.h (with Cocoa.h in the PTH file):
- PTH generation time improves by 5%
- PTH reading improves by 0.3%.
llvm-svn: 63072 | 
| | 
| 
| 
| 
| 
| 
| | to crash when given an instantiation location.  Thanks to Fariborz for
the testcase.
llvm-svn: 63057 | 
| | 
| 
| 
| | llvm-svn: 63054 | 
| | 
| 
| 
| | llvm-svn: 63047 | 
| | 
| 
| 
| 
| 
| | will help improve gradual versioning of PTH files instead of relying that the PTH table is at a fixed offset.
llvm-svn: 63045 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | instantiation history in an effort to speed up c99-intconst-1.c.
Now that multiple nested instantiations are allowed, we just
make them and don't pay the cost of lookups.  With the other
changes that went in before this, reverting this is actually
a speedup for c99-intconst-1.c, speeding it up from 1.96s to 1.80s,
and preserves much better loc info.
llvm-svn: 63036 | 
| | 
| 
| 
| 
| 
| | history
llvm-svn: 63035 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Token now has a class of kinds for "literals", which include 
numeric constants, strings, etc.  These tokens can optionally have
a pointer to the start of the token in the lexer buffer.  This 
makes it faster to get spelling and do other gymnastics, because we
don't have to go through source locations.
This change is performance neutral, but will make other changes
more feasible down the road.
llvm-svn: 63028 | 
| | 
| 
| 
| 
| 
| | unique the Filenames in #line directives, assigning them UIDs.
llvm-svn: 63010 | 
| | 
| 
| 
| | llvm-svn: 63003 | 
| | 
| 
| 
| | llvm-svn: 63000 | 
| | 
| 
| 
| 
| 
| | we just discard them.
llvm-svn: 62999 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This reduces fsyntax-only time on c99-intconst-1.c from 2.43s down to 
2.01s (20%), reducing the number of fileid lookups from 2529040 linear 
and 64771121 binary to 5625902 linear and 4151182 binary.
This knocks getFileID down to only 4.6% of compile time on this testcase.
At this point, malloc/free is over 35% of compile time, primarily allocating
MacroArgs objects and their argument preexpansion vectors.
I don't feel like malloc avoiding right now, so I'm just going to call
this good.
llvm-svn: 62994 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | of a macro.  Since these tokens may themselves be from macro 
expansions, we need to resolve down to the spelling loc when the
macro ends up being instantiated.  Instead of resolving this for
each token expanded from the macro definition, just do it once when
the macro is defined.  This speeds up clang on c99-intconst-1.c from
2.66s to 2.43s (9.5%), reducing the FileID lookups from 407244 linear and
114175649 binary to 2529040 linear and 64771121 binary.
llvm-svn: 62993 | 
| | 
| 
| 
| 
| 
| 
| 
| | per token lexed from it.  This speeds up clang on c99-intconst-1.c from
the GCC testsuite from 3.64s to 2.66s (36%).  This reduces the number of
binary search FileID lookups from 251570522 to 114175649 on this testcase.
llvm-svn: 62992 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | ground work for implementing #line, and fixes the "out of macro ID's" 
problem.
There is nothing particularly tricky about the code, other than the
very performance sensitive SourceManager::getFileID() method.
llvm-svn: 62978 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | Refactor how the preprocessor changes a token from being an tok::identifier to a 
keyword (e.g. tok::kw_for).  Instead of doing this in HandleIdentifier, hoist this
common case out into the caller, so that every keyword doesn't have to go through
HandleIdentifier.  This drops time in HandleIdentifier from 1.25ms to .62ms, and
speeds up clang -Eonly with PTH by about 1%.
llvm-svn: 62855 | 
| | 
| 
| 
| | llvm-svn: 62819 | 
| | 
| 
| 
| 
| 
| 
| 
| | load is always aligned.
I verified that the bswap doesn't occur in the assembly code on x86.
llvm-svn: 62815 | 
| | 
| 
| 
| 
| 
| | descriptive.
llvm-svn: 62775 | 
| | 
| 
| 
| 
| 
| | token data in PTHLexer::getSourceLocation().
llvm-svn: 62725 | 
| | 
| 
| 
| | 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: 62673 | 
| | 
| 
| 
| | llvm-svn: 62672 | 
| | 
| 
| 
| | llvm-svn: 62671 | 
| | 
| 
| 
| 
| 
| | file, just load them directly as ints.
llvm-svn: 62668 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| | loads.  This reduces user time but increases system time because of the slightly larger PTH file.  Although there is no performance win on Cocoa.h and -Eonly, overall this seems like a good step.
llvm-svn: 62542 | 
| | 
| 
| 
| 
| 
| 
| | safe because a #line can change the file characteristic on a per-loc
basis.
llvm-svn: 62502 | 
| | 
| 
| 
| 
| 
| 
| | safe because a #line can change the file characteristic on a per-loc
basis.
llvm-svn: 62501 | 
| | 
| 
| 
| 
| 
| | no longer such thing as a non-canonical FileID.
llvm-svn: 62499 | 
| | 
| 
| 
| 
| 
| | addresses <rdar://problem/6506035>.
llvm-svn: 62498 | 
| | 
| 
| 
| 
| 
| | ScratchBuffer.
llvm-svn: 62492 | 
| | 
| 
| 
| 
| 
| 
| | SourceLocation.  This requires making some cleanups to token pasting
and _Pragma expansion.
llvm-svn: 62490 | 
| | 
| 
| 
| 
| 
| | Anders noticed.
llvm-svn: 62472 | 
| | 
| 
| 
| 
| 
| | into PTHLexer::Lex.  This speeds up the user time of PTH -Eonly by another 2ms (4.4%)
llvm-svn: 62454 | 
| | 
| 
| 
| | llvm-svn: 62450 | 
| | 
| 
| 
| 
| 
| 
| | instead of assembling from bytes.  This speeds up -Eonly PTH reading 
of cocoa.h by about 2ms, which is 4.2%.
llvm-svn: 62447 | 
| | 
| 
| 
| 
| 
| | copies.  I verified that this causes no performance change in PTH.
llvm-svn: 62445 | 
| | 
| 
| 
| 
| 
| 
| | internally.  This is just a cleanup that reduces the need to cast to
unsigned char before assembling a larger integer.
llvm-svn: 62442 | 
| | 
| 
| 
| 
| 
| 
| 
| | the chunk ID not the file ID.  This exposes problems in 
TextDiagnosticPrinter where it should have been using the canonical
file ID but wasn't.  Fix these along the way.
llvm-svn: 62427 | 
| | 
| 
| 
| | llvm-svn: 62426 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | method.  This lets us clean up the interface and make it more obvious that
this method is *really really* _Pragma specific.
Note that _Pragma handling uglifies the Lexer in the critical path.  It would
be very interesting to consider making _Pragma remapping be a new special
lexer class of its own.
llvm-svn: 62425 | 
| | 
| 
| 
| | llvm-svn: 62424 |