History log of /external/clang/lib/Serialization/GlobalModuleIndex.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
ef8225444452a1486bd721f3285301fe84643b00 21-Jul-2014 Stephen Hines <srhines@google.com> Update Clang for rebase to r212749.

This also fixes a small issue with arm_neon.h not being generated always.

Includes a cherry-pick of:
r213450 - fixes mac-specific header issue
r213126 - removes a default -Bsymbolic on Android

Change-Id: I2a790a0f5d3b2aab11de596fc3a74e7cbc99081d
/external/clang/lib/Serialization/GlobalModuleIndex.cpp
6bcf27bb9a4b5c3f79cb44c0e4654a6d7619ad89 29-May-2014 Stephen Hines <srhines@google.com> Update Clang for 3.5 rebase (r209713).

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

Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/lib/Serialization/GlobalModuleIndex.cpp
28ce23a550d386b32aa60abbbf308d164992eb1e 25-Oct-2013 Rafael Espindola <rafael.espindola@gmail.com> I am about to change llvm::MemoryBuffer::getFile take take a Twine. Change
clang first so that the build still works.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193428 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Serialization/GlobalModuleIndex.cpp
70e7aeccbf5856a84f81366c6c1a0c0c01e70063 05-Jul-2013 Rafael Espindola <rafael.espindola@gmail.com> Use llvm::sys::fs::createUniqueFile.

Include a test that clang now produces output files with permissions matching
the umask.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185727 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Serialization/GlobalModuleIndex.cpp
8229d22e6449851b89361bf2f41804557328be63 12-Jun-2013 Rafael Espindola <rafael.espindola@gmail.com> Include Path.h instead of PathV2.h.

I am about to move PathV2.h to Path.h.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183795 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Serialization/GlobalModuleIndex.cpp
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/lib/Serialization/GlobalModuleIndex.cpp
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/lib/Serialization/GlobalModuleIndex.cpp
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/lib/Serialization/GlobalModuleIndex.cpp
ea14a8799f2a6d139491483151cee4341ef1a73e 08-Feb-2013 Douglas Gregor <dgregor@apple.com> Never cache the result of a module file lookup.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174744 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Serialization/GlobalModuleIndex.cpp
8e31d064e7543dde6e4205d5b27a95c96a4c3a4e 06-Feb-2013 Douglas Gregor <dgregor@apple.com> Eliminate a race condition with the global module index.

Essentially, a module file on disk could change size between the time
we stat() it and the time we open it, and we need to be robust against
such a problem.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174529 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Serialization/GlobalModuleIndex.cpp
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/lib/Serialization/GlobalModuleIndex.cpp
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/lib/Serialization/GlobalModuleIndex.cpp
1d32133b44487d9e98412e373d693416b05920bb 25-Jan-2013 NAKAMURA Takumi <geek4civic@gmail.com> Serialization/GlobalModuleIndex.cpp: Fixup r173405, <cstdio>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173408 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Serialization/GlobalModuleIndex.cpp
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/lib/Serialization/GlobalModuleIndex.cpp
d2db16f59601bc028f4f973990cc6d4abe95b91a 24-Jan-2013 NAKAMURA Takumi <geek4civic@gmail.com> clang/GlobalModuleIndex: Don't open the same file twice. Use raw_fd_ostream(fd, ...) instead.

FIXME: PathV2::unique_file() is assumed to open the file with binary mode on win32.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173330 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Serialization/GlobalModuleIndex.cpp
5100135ecf29d4246e6bd34318da9eb22c16b86a 23-Jan-2013 Douglas Gregor <dgregor@apple.com> Fix for case-sensitive file systems. Ugh

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173303 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Serialization/GlobalModuleIndex.cpp
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/lib/Serialization/GlobalModuleIndex.cpp