*Huge* improvement over the amount of deserializing that we do for C++ lookup.
e.g, if he have the Carbon header precompiled and include it on a file containing this:
int x;
these are the before/after stats:
BEFORE:
*** AST File Statistics:
578 stat cache hits
4 stat cache misses
548/30654 source location entries read (1.787695%)
15907/16501 types read (96.400223%)
53525/59955 declarations read (89.275291%)
33993/43525 identifiers read (78.099945%)
41516/51891 statements read (80.006165%)
77/5317 macros read (1.448185%)
0/6335 lexical declcontexts read (0.000000%)
1/5424 visible declcontexts read (0.018437%)
AFTER using the on-disk table:
*** AST File Statistics:
578 stat cache hits
4 stat cache misses
548/30654 source location entries read (1.787695%)
10/16501 types read (0.060602%)
9/59955 declarations read (0.015011%)
161/43525 identifiers read (0.369902%)
20/51891 statements read (0.038542%)
6/5317 macros read (0.112846%)
0/6335 lexical declcontexts read (0.000000%)
2/5424 visible declcontexts read (0.036873%)
There's only one issue affecting mostly the precompiled preambles which I will address soon.
llvm-svn: 111636
Now all classes derived from Attr are generated from TableGen.
Additionally, Attr* is no longer its own linked list; SmallVectors or
Attr* are used. The accompanying LLVM commit contains the updates to
TableGen necessary for this.
Some other notes about newly-generated attribute classes:
- The constructor arguments are a SourceLocation and a Context&,
followed by the attributes arguments in the order that they were
defined in Attr.td
- Every argument in Attr.td has an appropriate accessor named getFoo,
and there are sometimes a few extra ones (such as to get the length
of a variadic argument).
Additionally, specific_attr_iterator has been introduced, which will
iterate over an AttrVec, but only over attributes of a certain type. It
can be accessed through either Decl::specific_attr_begin/end or
the global functions of the same name.
llvm-svn: 111455
to the consumer until the DeclContext is fully prepared.
Before, due to recursive loading, we could be in a situation where we would try to deserialize the decls of a DeclContext which was already doing that, and bad things would happen. In the specific case I encountered, the lexical decls would
form a cycle and we would enter infinite loop territory.
llvm-svn: 109857
- Stop reading in (and thus deserializing) every declaration in the TU when creating a dependent PCH.
- Switch the storage of a decl context's lexical declarations to a blob containing the IDs instead of a record. This is the only sane way of supporting update records later on.
llvm-svn: 109474
This has 2 (slight) advantages:
-Make explicit at getBody()'s callsite that we expect/handle only CompoundStmt and not CXXTryStmt.
-Better tracking of Decl::getBody()'s callsites.
llvm-svn: 107771
Before this commit, visible decls added before deserialization were ignored.
This was not an issue since name lookup (that usually comes before the addition) forces deserialization
but it is an issue for lazily declared class implicit members.
We can use a PCH'ed <string> now.
llvm-svn: 107596
declarations for implicit default constructors, copy constructors,
copy assignment operators, and destructors. On a "simple" translation
unit that includes a bunch of C++ standard library headers, we
generate relatively few of these implicit declarations now:
4/159 implicit default constructors created
18/236 implicit copy constructors created
70/241 implicit copy assignment operators created
0/173 implicit destructors created
And, on this translation unit, this optimization doesn't really
provide any benefit. I'll do some more performance measurements soon,
but this completes the implementation work for <rdar://problem/8151045>.
llvm-svn: 107551
attribute as part of the calculation. Sema::MarkDeclReferenced(), and
a few other places, want only to consider the "used" bit to determine,
e.g, whether to perform template instantiation. Fixes a linkage issue
with Boost.Serialization.
llvm-svn: 106252
bring in the entire lookup table at once.
Also, give ExternalSemaSource's vtable a home. This is important because otherwise
any reference to it will cause RTTI to be emitted, and since clang is compiled
with -fno-rtti, that RTTI will contain unresolved references (to ExternalASTSource's
RTTI). So this change makes it possible to subclass ExternalSemaSource from projects
compiled with RTTI, as long as the subclass's home is compiled with -fno-rtti.
llvm-svn: 105268
The macros required for DeclNodes use have changed to match the use of
StmtNodes. The FooFirst enumerator constants have been named firstFoo
to match usage elsewhere.
llvm-svn: 105165
way that C does. Among other differences, elaborated type specifiers
are defined to skip "non-types", which, as you might imagine, does not
include typedefs. Rework our use of IDNS masks to capture the semantics
of different kinds of declarations better, and remove most current lookup
filters. Removing the last remaining filter is more complicated and will
happen in a separate patch.
Fixes PR 6885 as well some spectrum of unfiled bugs.
llvm-svn: 102164
dyn_cast) invocations for C++ and Objective-C types, declarations,
expressions, and statements. The statistics will be printed when
-print-stats is provided to Clang -cc1, with results such as:
277073 clang - Number of checks for C++ declaration nodes
13311 clang - Number of checks for C++ expression nodes
18 clang - Number of checks for C++ statement nodes
174182 clang - Number of checks for C++ type nodes
92300 clang - Number of checks for Objective-C declaration nodes
9800 clang - Number of checks for Objective-C expression nodes
7 clang - Number of checks for Objective-C statement nodes
65733 clang - Number of checks for Objective-C type nodes
The statistics are only gathered when NDEBUG is not defined, since
they introduce potentially-expensive operations into very low-level
routines (isa).
llvm-svn: 99912
storage for that partial diagnostic via the ASTContext's
BumpPtrAllocator rather than using up slots in the ASTContext's
cache. Now that we do this, we don't have to worry about destroying
dependent diagnostics when destroying a DependentStoredDeclsMap.
llvm-svn: 99854
cache of PartialDiagnostic::Storage objects into an allocator within
the ASTContext. This eliminates a significant amount of malloc
traffic, for a 10% performance improvement in -fsyntax-only wall-clock
time with 403.gcc's combine.c.
Also, eliminate the RequireNonAbstractType hack I put in earlier,
which was but a symptom of this larger problem.
Fixes <rdar://problem/7806091>.
llvm-svn: 99849
templates. So delay access-control diagnostics when (for example) the target
of a friend declaration is a specific specialization of a template.
I was surprised to find that this was required for an access-controlled selfhost.
llvm-svn: 99383
I'm expecting this portion of the AST to grow and change, and I'd like to
be able to do that with minimal recompilation. If this proves unnecessary
when access control is fully-implemented, I'll fold the classes back into
DeclCXX.h.
llvm-svn: 98249
injected class name of a class template or class template partial specialization.
This is a non-canonical type; the canonical type is still a template
specialization type. This becomes the TypeForDecl of the pattern declaration,
which cleans up some amount of code (and complicates some other parts, but
whatever).
Fixes PR6326 and probably a few others, primarily by re-establishing a few
invariants about TypeLoc sizes.
llvm-svn: 98134
storing the set of StoredDeclsMaps in an internal vector of void*.
This isn't an ideal solution, but for the time being this fixes a
major memory leak with these DenseMaps not being freed.
Fixes: <rdar://problem/7634755>
llvm-svn: 95861
translation unit. This is temporary for function and block parameters;
template parameters can just stay this way, since Templates aren't
DeclContexts. This gives us the nice property that everything created
in a record DC should have access in C++.
llvm-svn: 94122
to merge the local instantiation scope with the outer local
instantiation scope, so that we can instantiate declarations from the
function owning the local class. Fixes an assert while instantiating
Boost.MPL's BOOST_MPL_ASSERT_MSG.
llvm-svn: 93651
are a couple of O(n^2) operations in this, some analogous to the usual O(n^2)
redeclaration problem and some not. In particular, retroactively removing
shadow declarations when they're hidden by later decls is pretty unfortunate.
I'm not yet convinced it's worse than the alternative, though.
llvm-svn: 91045
DeclContext, so they don't completely disappear from the AST.
I don't particularly like this fix, but I don't see any obviously better way
to deal with it, and I think it's pretty clearly an improvement; comments
welcome.
llvm-svn: 90835
ASTContext instead of malloc. Besides reducing malloc traffic, this
also removes a source of memory leaks when using a BumpPtrAllocator
for the allocator of ASTContext. There are still leaks when using
MallocAllocator because Decl::Destroy() isn't fully finished.
Fixes: <rdar://problem/7431556>
llvm-svn: 90174
two classes, one for typenames and one for values; this seems to have some
support from Doug if not necessarily from the extremely-vague-on-this-point
standard. Track the location of the 'typename' keyword in a using-typename
decl. Make a new lookup result for unresolved values and deal with it in
most places.
llvm-svn: 89184
current DeclContext. These "imaginary" declarations pose issues for
clients searching DeclContext for actual declarations. Instead,
register them for name lookup, and add the ObjCInterfaceDecl later to
the DeclContext when we hit an actual @interface declaration.
This also fixes a bug where the invariant that the Decls in a
DeclContext are sorted in order of their appearance is no longer
violated. What could happen is that an @class causes an
ObjCInterfaceDecl to get added first to the DeclContext, then the
ObjCClassDecl itself is added, and then later the SourceLocation of
the ObjCInterfaceDecl is updated with the correct location (which is
later in the file). This breaks an assumed invariant in
ResolveLocation.cpp (and possibly other clients).
llvm-svn: 89160
