Commit Graph

46 Commits

Author SHA1 Message Date
Douglas Gregor 935bc7a214 Make the loading of information attached to an IdentifierInfo from an
AST file more lazy, so that we don't eagerly load that information for
all known identifiers each time a new AST file is loaded. The eager
reloading made some sense in the context of precompiled headers, since
very few identifiers were defined before PCH load time. With modules,
however, a huge amount of code can get parsed before we see an
@import, so laziness becomes important here.

The approach taken to make this information lazy is fairly simple:
when we load a new AST file, we mark all of the existing identifiers
as being out-of-date. Whenever we want to access information that may
come from an AST (e.g., whether the identifier has a macro definition,
or what top-level declarations have that name), we check the
out-of-date bit and, if it's set, ask the AST reader to update the
IdentifierInfo from the AST files. The update is a merge, and we now
take care to merge declarations before/after imports with declarations
from multiple imports.

The results of this optimization are fairly dramatic. On a small
application that brings in 14 non-trivial modules, this takes modules
from being > 3x slower than a "perfect" PCH file down to 30% slower
for a full rebuild. A partial rebuild (where the PCH file or modules
can be re-used) is down to 7% slower. Making the PCH file just a
little imperfect (e.g., adding two smallish modules used by a bunch of
.m files that aren't in the PCH file) tips the scales in favor of the
modules approach, with 24% faster partial rebuilds.

This is just a first step; the lazy scheme could possibly be improved
by adding versioning, so we don't search into modules we already
searched. Moreover, we'll need similar lazy schemes for all of the
other lookup data structures, such as DeclContexts.

llvm-svn: 143100
2011-10-27 09:33:13 +00:00
Douglas Gregor ebf0049901 For modules, all macros that aren't include guards are implicitly
public. Add a __private_macro__ directive to hide a macro, similar to
the __module_private__ declaration specifier.

llvm-svn: 142188
2011-10-17 15:32:29 +00:00
Douglas Gregor 71129d5e9e When building a module, use the macro definitions on the command line
as part of the hash rather than ignoring them. This means we'll end up
building more module variants (overall), but it allows configuration
macros such as NDEBUG to work so long as they're specified via command
line. More to come in this space.

llvm-svn: 142187
2011-10-17 14:55:37 +00:00
Douglas Gregor 44e688d46a Introduce an opt-in warning when a module is being implicitly built
from sources.

llvm-svn: 140746
2011-09-29 00:52:27 +00:00
Douglas Gregor 5d1bee253c When we load header file information from the external source (i.e.,
the AST reader), merge that header file information with whatever
header file information we already have. Otherwise, we might forget
something we already knew (e.g., that the header was #import'd already).

llvm-svn: 139979
2011-09-17 05:35:18 +00:00
Douglas Gregor 2fd3d401f9 With modules, we can end up loading a new module after we've seen an
arbitrary amount of code. This forces us to stage the AST writer more
strictly, ensuring that we don't assign a declaration ID to a
declaration until after we're certain that no more modules will get
loaded.

llvm-svn: 139974
2011-09-17 00:05:03 +00:00
Douglas Gregor 97eec24b0b Add an experimental flag -fauto-module-import that automatically turns
#include or #import direcctives of framework headers into module
imports of the corresponding framework module.

llvm-svn: 139860
2011-09-15 22:00:41 +00:00
Douglas Gregor f31caeec88 Add test case for mutually recursive modules
llvm-svn: 139838
2011-09-15 20:54:06 +00:00
Douglas Gregor 6137d32c1b When we load the first module, make sure that we wire up the ASTConsumer to the newly-created ASTReader. This makes sure that CodeGen sees the declarations it is interested in
llvm-svn: 139824
2011-09-15 18:47:32 +00:00
Douglas Gregor 8455e76fa1 Teach LangOptions::resetNonModularOptions to actually do what it says it does
llvm-svn: 139791
2011-09-15 14:56:27 +00:00
Douglas Gregor 21931efc4d Make -E work with module imports
llvm-svn: 139750
2011-09-14 23:13:09 +00:00
Douglas Gregor d7910e95bd Don't try to write a macro offset for an identifier that names a non-exported macro, for real this time
llvm-svn: 139745
2011-09-14 22:14:14 +00:00
Douglas Gregor 4fe9b18182 Revert my exported-macro hackery. Something is amiss
llvm-svn: 139734
2011-09-14 20:57:14 +00:00
Douglas Gregor 4184ab0b26 Don't try to write a macro offset for an identifier that names a non-exported macro
llvm-svn: 139728
2011-09-14 20:36:30 +00:00
Douglas Gregor e162dd46f6 Add test for the driver's handling of modules
llvm-svn: 139727
2011-09-14 20:29:10 +00:00
Douglas Gregor 1735f4e752 For modules, use a hash of the compiler version, language options, and
target triple to separate modules built under different
conditions. The hash is used to create a subdirectory in the module
cache path where other invocations of the compiler (with the same
version, language options, etc.) can find the precompiled modules.

llvm-svn: 139662
2011-09-13 23:15:45 +00:00
Douglas Gregor f1312a828a When building a module on-demand, clear out the "non-modular" language
and preprocessor options (such as macro definitions) first.

llvm-svn: 139638
2011-09-13 20:44:41 +00:00
Douglas Gregor c2ae880070 Switch the serialization of LangOptions over to use the .def file. We
should no longer have the serialization of LangOptions out of sync
with the structure itself (yay).

llvm-svn: 139613
2011-09-13 18:26:39 +00:00
Douglas Gregor a057a58048 Add a struct-size check for modules when dealing with module-private fields
llvm-svn: 139597
2011-09-13 15:37:05 +00:00
Douglas Gregor faeb1d4658 When an import statement fails to find a module in the module cache,
but there is a corresponding umbrella header in a framework, build the
module on-the-fly so it can be immediately loaded at the import
statement. This is very much proof-of-concept code, with details to be
fleshed out over time.

llvm-svn: 139558
2011-09-12 23:31:24 +00:00
Douglas Gregor 1e44e02292 Introduce a cc1-level option to provide the path to the module cache,
where the compiler will look for module files. Eliminates the
egregious hack where we looked into the header search paths for
modules.

llvm-svn: 139538
2011-09-12 20:41:59 +00:00
Douglas Gregor 41866816ce Diagnose attempt to mark function-local declarations as __module_private__.
llvm-svn: 139519
2011-09-12 18:37:38 +00:00
Douglas Gregor 3baa6702ab Allow __module_private__ on fields
llvm-svn: 139499
2011-09-12 16:11:24 +00:00
Douglas Gregor fc33bcfc4a Remove the restriction on module-private friends. Since the friend
declaration may be the first declaration, we want the ability to that
declaration to be marked module-private.

llvm-svn: 139497
2011-09-12 15:48:15 +00:00
Douglas Gregor abc5fbe9d6 Don't crash when we fail to load a module. It's unbecoming of a
well-bred compiler like Clang.

llvm-svn: 139442
2011-09-10 00:30:18 +00:00
Douglas Gregor 6422642a1d Friends cannot be declared module-private
llvm-svn: 139411
2011-09-09 21:14:29 +00:00
Douglas Gregor 3c7cd6a0c4 Specializations cannot be module-hidden. Diagnose attempts to do so.
llvm-svn: 139406
2011-09-09 20:53:38 +00:00
Douglas Gregor 2820e6923a __module_private__ is inherited by redeclarations of an entity, and
must also be present of the first declaration of that entity.

llvm-svn: 139384
2011-09-09 19:05:14 +00:00
Douglas Gregor ef15bdbe1a Propagate __module_private__ from previous declarations to later
declarations.

llvm-svn: 139380
2011-09-09 18:32:39 +00:00
Douglas Gregor 26701a4371 Modules: introduce the __module_private__ declaration specifier, which
indicates that a declaration is only visible within the module it is
declared in.

llvm-svn: 139348
2011-09-09 02:06:17 +00:00
Douglas Gregor 6ac0b717b4 Make test slightly trickier
llvm-svn: 138957
2011-09-01 19:02:18 +00:00
Douglas Gregor 4a69c2e6c5 Modules hide macro definitions by default, so that silly things like
include guards don't show up as macro definitions in every translation
unit that imports a module. Macro definitions can, however, be
exported with the intentionally-ugly #__export_macro__
directive. Implement this feature by not even bothering to serialize
non-exported macros to a module, because clients of that module need
not (should not) know that these macros even exist.

llvm-svn: 138943
2011-09-01 17:04:32 +00:00
Argyrios Kyrtzidis 7d847c9fd8 Support importing of ObjC categories from modules.
The initial incentive was to fix a crash when PCH chaining categories
to an interface, but the fix was done in the "modules way" that I hear
is popular with the kids these days.

Each module stores the local chain of categories and we combine them
when the interface is loaded. We also warn if non-dependent modules
introduce duplicate named categories.

llvm-svn: 138926
2011-09-01 00:58:55 +00:00
Douglas Gregor ca97589f7d Switch __import__ over to __import_module__, so we don't conflict with
existing practice with Python extension modules. Not that Python
extension modules should be using a double-underscored identifier
anyway, but...

llvm-svn: 138870
2011-08-31 18:19:09 +00:00
Douglas Gregor d90c3c92d5 Take an entirely different approach to handling the "parsing" of
__import__ within the preprocessor, since the prior one foolishly
assumed that Preprocessor::Lex() was re-entrant. We now handle
__import__ at the top level (only), after macro expansion. This should
fix the buildbot failures.

llvm-svn: 138704
2011-08-27 06:37:51 +00:00
Douglas Gregor e89397ac1e XFAIL one of the module tests on win32, until we figure out what's happening
llvm-svn: 138688
2011-08-27 00:29:32 +00:00
Douglas Gregor 081425343b Introduce support for a simple module import declaration, which
loads the named module. The syntax itself is intentionally hideous and
will be replaced at some later point with something more
palatable. For now, we're focusing on the semantics:
  - Module imports are handled first by the preprocessor (to get macro
  definitions) and then the same tokens are also handled by the parser
  (to get declarations). If both happen (as in normal compilation),
  the second one is redundant, because we currently have no way to
  hide macros or declarations when loading a module. Chris gets credit
  for this mad-but-workable scheme.
  - The Preprocessor now holds on to a reference to a module loader,
  which is responsible for loading named modules. CompilerInstance is
  the only important module loader: it now knows how to create and
  wire up an AST reader on demand to actually perform the module load.
  - We search for modules in the include path, using the module name
  with the suffix ".pcm" (precompiled module) for the file name. This
  is a temporary hack; we hope to improve the situation in the
  future.

llvm-svn: 138679
2011-08-26 23:56:07 +00:00
Douglas Gregor 69f74f80db Introduce a -cc1 option "-emit-module", that creates a binary module
from the given source. -emit-module behaves similarly to -emit-pch,
except that Sema is somewhat more strict about the contents of
-emit-module. In the future, there are likely to be more interesting
differences.

llvm-svn: 138595
2011-08-25 22:30:56 +00:00
Douglas Gregor c10edd6dd0 Use the module manager's search facility to look for methods with a
given selector, rather than walking the chain backwards. Teach its
visitor how to merge multiple result sets into a single result set,
combining the results of selector lookup in several different modules
into a single result set.

llvm-svn: 138556
2011-08-25 14:51:20 +00:00
Douglas Gregor 1257f97003 Introduce a depth-first search of modules into the module manager,
which supports both pre-order and post-order traversal via a visitor
mechanism. Use this depth-first search with a post-order traversal to
give predictable ordering semantics when walking all of the lexical
declarations in the translation unit.

Eventually, module imports will occur in the source code rather than
at the beginning, and we'll have to revisit this walk.

llvm-svn: 138490
2011-08-24 21:27:34 +00:00
Douglas Gregor 94619c81fc In the AST reader, switch name lookup within a DeclContect over to the
module DAG-based lookup scheme. This required some reshuffling, so
that each module stores its own mapping from DeclContexts to their
lexical and visible sets for those DeclContexts (rather than one big
"chain"). 

Overall, this allows simple qualified name lookup into the translation
unit to gather results from multiple modules, with the lookup results
in module B shadowing the lookup results in module A when B imports A.

Walking all of the lexical declarations in a module DAG is still a
mess; we'll end up walking the loaded module list backwards, which
works fine for chained PCH but doesn't make sense in a DAG. I'll
tackle this issue as a separate commit.

llvm-svn: 138463
2011-08-24 19:03:07 +00:00
Douglas Gregor b36fc536d2 Make the loading of multiple records for the same identifier (from
different modules) more robust. It already handled (simple) merges of
the set of declarations attached to that identifier, so add a test
case that shows us getting two different declarations for the same
identifier (one struct, one function) from different modules, and are
able to use both of them.

llvm-svn: 138189
2011-08-20 05:09:43 +00:00
Douglas Gregor ab443b9da5 Introduce a module visitation function that starts at the top-level
modules (those that no other module depends on) and performs a search
over all of the modules, visiting a new module only when all of the
modules that depend on it have already been visited. The visitor can
abort the search for all modules that a module depends on, which
allows us to minimize the number of lookups necessary when performing
a search.

Switch identifier lookup from a linear walk over the set of modules to
this module visitation operation. The behavior is the same for simple
PCH and chained PCH, but provides the proper search order for
modules. Verified with printf debugging, since we don't have enough in
place to actually test this.

llvm-svn: 138187
2011-08-20 04:39:52 +00:00
Douglas Gregor 4dd3e948ef Teach ModuleManager::addModule() to check whether a particular module
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.

This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.

Note that this version moves the file-opening logic into the module
manager, rather than splitting it between the module manager and the
AST reader. More importantly, it properly handles the
weird-but-possibly-useful case of loading an AST file from "-".

llvm-svn: 138030
2011-08-19 02:29:29 +00:00
Chad Rosier 222e187e33 Temporarily revert r137925 to appease buildbots. Original commit message:
Teach ModuleManager::addModule() to check whether a particular module
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.

This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.

llvm-svn: 137971
2011-08-18 19:06:24 +00:00
Douglas Gregor 914eb7c18a Teach ModuleManager::addModule() to check whether a particular module
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.

This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.

llvm-svn: 137925
2011-08-18 04:41:58 +00:00