History log of /external/clang/include/clang/Serialization/GlobalModuleIndex.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
6bcf27bb9a4b5c3f79cb44c0e4654a6d7619ad89 29-May-2014 Stephen Hines <srhines@google.com> Update Clang for 3.5 rebase (r209713).

Change-Id: I8c9133b0f8f776dc915f270b60f94962e771bc83
/external/clang/include/clang/Serialization/GlobalModuleIndex.h
651f13cea278ec967336033dd032faef0e9fc2ec 24-Apr-2014 Stephen Hines <srhines@google.com> Updated to Clang 3.5a.

Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/include/clang/Serialization/GlobalModuleIndex.h
809d254c1f1521c141c8807638c29d67b50ebf29 24-Aug-2013 Benjamin Kramer <benny.kra@googlemail.com> This wasn't headers, just missing namespaces.

/me bows head in shame.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189172 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Serialization/GlobalModuleIndex.h
87f9d81d0ab806dcf6ca50a0c068dcb2ba7f51b3 18-Apr-2013 Argyrios Kyrtzidis <akyrtzi@gmail.com> [Modules] Use global index to improve typo correction performance

Typo correction for an unqualified name needs to walk through all of the identifier tables of all modules.
When we have a global index, just walk its identifier table only.

rdar://13425732

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179730 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Serialization/GlobalModuleIndex.h
fa69fc19121da3fc5673ccc00d4e8afa5b540a4f 22-Mar-2013 Douglas Gregor <dgregor@apple.com> <rdar://problem/13479539> Simplify ModuleManager/GlobalModuleIndex interaction to eliminate a pile of extraneous stats().

The refactoring in r177367 introduced a serious performance bug where
the "lazy" resolution of module file names in the global module index
to actual module file entries in the module manager would perform
repeated negative stats(). The new interaction requires the module
manager to inform the global module index when a module file has been
loaded, eliminating the extraneous stat()s and a bunch of bookkeeping
on both sides.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177750 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Serialization/GlobalModuleIndex.h
a5a3e01c504c00b1860286540090695ec0167531 19-Mar-2013 Douglas Gregor <dgregor@apple.com> Remove stray semicolon

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177370 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Serialization/GlobalModuleIndex.h
677e15ffee2ecc9c1c8f46fd77cab4b5afb59640 19-Mar-2013 Douglas Gregor <dgregor@apple.com> <rdar://problem/13363214> Eliminate race condition between module rebuild and the global module index.

The global module index was querying the file manager for each of the
module files it knows about at load time, to prune out any out-of-date
information. The file manager would then cache the results of the
stat() falls used to find that module file.

Later, the same translation unit could end up trying to import one of the
module files that had previously been ignored by the module cache, but
after some other Clang instance rebuilt the module file to bring it
up-to-date. The stale stat() results in the file manager would
trigger a second rebuild of the already-up-to-date module, causing
failures down the line.

The global module index now lazily resolves its module file references
to actual AST reader module files only after the module file has been
loaded, eliminating the stat-caching race. Moreover, the AST reader
can communicate to its caller that a module file is missing (rather
than simply being out-of-date), allowing us to simplify the
module-loading logic and allowing the compiler to recover if a
dependent module file ends up getting deleted.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177367 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Serialization/GlobalModuleIndex.h
9ef9b8540a608a93efaaae1d26d94e8087c30b55 19-Feb-2013 David Blaikie <dblaikie@gmail.com> Use LLVM_DELETED_FUNCTION rather than '// do not implement' comments.

Also removes some redundant DNI comments on function declarations already
using the macro.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175465 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Serialization/GlobalModuleIndex.h
894719bf99cf0131d954c714179bb47eee472b91 28-Jan-2013 Douglas Gregor <dgregor@apple.com> ASTReader and profiling statistics indicate that implementing a method
pool in the global module index is not worthwhile. Update comments to
limit the scope of the global module index to identifiers.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173705 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Serialization/GlobalModuleIndex.h
188bdcd1aaf5e9f457cec6851707d7dc3e7bbb15 26-Jan-2013 Douglas Gregor <dgregor@apple.com> Improve coordination between the module manager and the global module
index, optimizing the operation that skips lookup in modules where we
know the identifier will not be found. This makes the global module
index optimization actually useful, providing an 8.5% speedup over
modules without the global module index for -fsyntax-only.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173529 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Serialization/GlobalModuleIndex.h
1a49d97d762570027863e9209af81d445e4f1502 25-Jan-2013 Douglas Gregor <dgregor@apple.com> Implement the reader of the global module index and wire it into the
AST reader.

The global module index tracks all of the identifiers known to a set
of module files. Lookup of those identifiers looks first in the global
module index, which returns the set of module files in which that
identifier can be found. The AST reader only needs to look into those
module files and any module files not known to the global index (e.g.,
because they were (re)built after the global index), reducing the
number of on-disk hash tables to visit. For an example source I'm
looking at, we go from 237844 total identifier lookups into on-disk
hash tables down to 126817.

Unfortunately, this does not translate into a performance advantage.
At best, it's a wash once the global module index has been built, but
that's ignore the cost of building the global module index (which
is itself fairly large). Profiles show that the global module index
code is far less efficient than it should be; optimizing it might give
enough of an advantage to justify its continued inclusion.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173405 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Serialization/GlobalModuleIndex.h
a6b00fc97669aa25d89ae9f202b05dfadfd0e324 23-Jan-2013 Douglas Gregor <dgregor@apple.com> Implement the writer side of the global module index.

The global module index is a "global" index for all of the module
files within a particular subdirectory in the module cache, which
keeps track of all of the "interesting" identifiers and selectors
known in each of the module files. One can perform a fast lookup in
the index to determine which module files will have more information
about entities with a particular name/selector. This information can
help eliminate redundant lookups into module files (a serious
performance problem) and help with creating auto-import/auto-include
Fix-Its.

The global module index is created or updated at the end of a
translation unit that has triggered a (re)build of a module by
scraping all of the .pcm files out of the module cache subdirectory,
so it catches everything. As with module rebuilds, we use the file
system's atomicity to synchronize.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173301 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Serialization/GlobalModuleIndex.h