| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Again, I tried to update cmake but it is untested.
llvm-svn: 67605
|
|
|
|
|
|
| |
file itself.
llvm-svn: 67340
|
|
|
|
|
|
|
|
| |
This allows the PTH file to stay 100% in fidelity with the source code and
defines away some weird cosmetic bugs for operations such as '-E' where
maintaining knowledge of the original literal representation is useful.
llvm-svn: 65361
|
|
|
|
|
|
|
|
| |
size to that of the *cleaned* spelling. This way 'getSpelling()' for literals in
the Preprocessor just works and doesn't read beyond the bounds of the cached
spelling buffer.
llvm-svn: 65354
|
|
|
|
|
|
| |
cached).
llvm-svn: 65148
|
|
|
|
| |
llvm-svn: 64556
|
|
|
|
|
|
| |
performance improvement on Cocoa.h (fsyntax-only+PTH).
llvm-svn: 64490
|
|
|
|
|
|
| |
directories (and negative stats too).
llvm-svn: 64477
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to use this stat information in the PTH file using a 'StatSysCallCache' object.
Performance impact (Cocoa.h, PTH):
- number of stat calls reduces from 1230 to 425
- fsyntax-only: time improves by 4.2%
We can reduce the number of stat calls to almost zero by caching negative stat
calls and directory stat calls in the PTH file as well.
llvm-svn: 64353
|
|
|
|
| |
llvm-svn: 64338
|
|
|
|
|
|
|
| |
actually *slightly* slower than the binary search. Since this is algorithmically
better, further performance tuning should be able to make this faster.
llvm-svn: 64326
|
|
|
|
|
|
| |
referenced by other tables.
llvm-svn: 64304
|
|
|
|
|
|
| |
'#endif'.
llvm-svn: 64250
|
|
|
|
|
|
| |
preparing for other changes within the loop.
llvm-svn: 64247
|
|
|
|
|
|
| |
with an on-disk chained hash table. This data structure is implemented using templates, and will be used to replace similar data structures. This change leads to no visibile performance impact on Cocoa.h, but now we only pay a price for the table on order with the number of files accessed and not the number in the PTH file.
llvm-svn: 64245
|
|
|
|
| |
llvm-svn: 64193
|
|
|
|
|
|
| |
on-disk chained hash table.
llvm-svn: 64192
|
|
|
|
|
|
|
|
|
| |
ContentCache objects to using a densemap and list, and allocating
the ContentCache objects from a bump pointer. This does not speed
up or slow down things substantially, but gives us control over
their alignment.
llvm-svn: 63628
|
|
|
|
| |
llvm-svn: 63097
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
entire file.
llvm-svn: 62414
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"FileID" a concept that is now enforced by the compiler's type checker
instead of yet-another-random-unsigned floating around.
This is an important distinction from the "FileID" currently tracked by
SourceLocation. *That* FileID may refer to the start of a file or to a
chunk within it. The new FileID *only* refers to the file (and its
#include stack and eventually #line data), it cannot refer to a chunk.
FileID is a completely opaque datatype to all clients, only SourceManager
is allowed to poke and prod it.
llvm-svn: 62407
|
|
|
|
| |
llvm-svn: 62402
|
|
|
|
|
|
|
| |
content cache directly. Content cache has a 1-1 mapping with fileentries,
whereas multiple FileIDs can be the same FileEntry.
llvm-svn: 62401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- IdentifierInfo can now (optionally) have its string data not be
co-located with itself. This is for use with PTH. This aspect is a
little gross, as getName() and getLength() now make assumptions
about a possible alternate representation of IdentifierInfo.
Perhaps we should make IdentifierInfo have virtual methods?
IdentifierTable:
- Added class "IdentifierInfoLookup" that can be used by
IdentifierTable to perform "string -> IdentifierInfo" lookups using
an auxilliary data structure. This is used by PTH.
- Perform tests show that IdentifierTable::get() does not slow down
because of the extra check for the IdentiferInfoLookup object (the
regular StringMap lookup does enough work to mitigate the impact of
an extra null pointer check).
- The upshot is that now that some IdentifierInfo objects might be
owned by the IdentiferInfoLookup object. This should be reviewed.
PTH:
- Modified PTHManager::GetIdentifierInfo to *not* insert entries in
IdentifierTable's string map, and instead create IdentifierInfo
objects on the fly when mapping from persistent IDs to
IdentifierInfos. This saves a ton of work with string copies,
hashing, and StringMap lookup and resizing. This change was
motivated because when processing source files in the PTH cache we
don't need to do any string -> IdentifierInfo lookups.
- PTHManager now subclasses IdentifierInfoLookup, allowing clients of
IdentifierTable to transparently use IdentifierInfo objects managed
by the PTH file. PTHManager resolves "string -> IdentifierInfo"
queries by doing a binary search over a sorted table of identifier
strings in the PTH file (the exact algorithm we use can be changed
as needed).
These changes lead to the following performance changes when using PTH on Cocoa.h:
- fsyntax-only: 10% performance improvement
- Eonly: 30% performance improvement
llvm-svn: 62273
|
|
|
|
|
|
|
|
| |
lexical order of the corresponding identifier strings. This will be used for a
forthcoming optimization. This slows down PTH generation time by 7%. We can
revert this change if the optimization proves to not be valuable.
llvm-svn: 62248
|
|
|
|
|
|
| |
character after each cached string.
llvm-svn: 61962
|
|
|
|
|
|
| |
after the spelling to accomodate sanity checking in LiteralSuppoert.cpp.
llvm-svn: 61956
|
|
|
|
| |
llvm-svn: 61910
|
|
|
|
|
|
| |
file. For Cocoa.h, this enlarges the PTH file by 310K (4%).
llvm-svn: 61909
|
|
|
|
|
|
| |
of the PTH generation data structures. No functionality change.
llvm-svn: 61902
|
|
|
|
| |
llvm-svn: 61786
|
|
|
|
|
|
|
| |
- This reduces the PTH size for Cocoa.h by 7%.
- The increases PTH -Eonly speed for Cocoa.h by 0.8%.
llvm-svn: 61377
|
|
|
|
|
|
|
|
| |
- Encode the token length with 2 bytes instead of 4.
- This reduces the size of the .pth file for Cocoa.h by 12%.
- This speeds up PTH time (-Eonly) on Cocoa.h by 1.6%.
llvm-svn: 61364
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Embed 'eom' tokens in PTH file.
- Use embedded 'eom' tokens to not lazily generate them in the PTHLexer.
This means that PTHLexer can always advance to the next token after
reading a token (instead of buffering tokens using a copy).
- Moved logic of 'ReadToken' into Lex. GetToken & ReadToken no longer exist.
- These changes result in a 3.3% speedup (-Eonly) on Cocoa.h.
- The code is a little gross. Many cleanups are possible and should be done.
llvm-svn: 61360
|
|
|
|
|
|
| |
#elseinformation as well.
llvm-svn: 60955
|
|
|
|
|
|
|
| |
- Added a side-table per each token-cached file with the preprocessor conditional stack. This tracks what #if's are matched with what #endifs and where their respective tokens are in the PTH file. This will allow for quick skipping of excluded conditional branches in the Preprocessor.
- Performance testing shows the addition of this information (without actually utilizing it) leads to no performance regressions.
llvm-svn: 60911
|
|
|
|
|
|
| |
absolute path.
llvm-svn: 60558
|
|
|
|
|
|
| |
Use an array instead of a DenseMap to cache persistent IDs -> IdentifierInfo*. This leads to a 4% speedup at -fsyntax-only using PTH.
llvm-svn: 60452
|
|
|
|
|
|
|
|
|
| |
- Output 32 bit integers using bit-shifting + write of individual bytes.
This is motivated because we aren't guaranteed to load 32-bit ints of the mmaped PTH file at 4-byte offsets.
- Don't emit flags for IdentifierInfos. These are lazily populated by the Preprocessor/Parser.
- Only write out tokens for files with absolute paths. This is potentially temporary, but simplifies things for now.
llvm-svn: 60435
|
|
|
|
|
|
|
|
| |
- a table including the IdentifierInfo data
- an index from persistent IdentifierInfo IDs to indices within this file.
- Enhance PTH generation to write out file map information, mapping inodes to tokens.
llvm-svn: 60132
|
|
|
|
| |
llvm-svn: 60086
|
|
|
|
| |
llvm-svn: 60077
|
|
|
|
|
|
| |
to CacheTokens.cpp.
llvm-svn: 60071
|
|
|
|
|
|
|
|
| |
the Backend output should be done in binary mode.
- I'd appreciate it if someone who has a Windows build could verify
this.
llvm-svn: 59221
|
|
llvm-svn: 57863
|