| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 42730
|
|
|
|
| |
llvm-svn: 42728
|
|
|
|
|
|
|
|
|
| |
Now instead of IdentifierInfo knowing anything about MacroInfo,
only the preprocessor knows. This makes MacroInfo truly private
to the Lex library (and its direct clients) instead of being
accessed in the Basic library.
llvm-svn: 42727
|
|
|
|
|
|
|
|
| |
(because all bitfields now fit in 32 bits). This shrinks the identifier
table for carbon.h from 1634428 to 1451424 bytes (12%) and has no impact
on compile time.
llvm-svn: 42723
|
|
|
|
|
|
|
|
|
|
| |
moves the MacroInfo pointer to a side hash table (which currently
lives in IdentifierTable.cpp). This removes a pointer from
Identifier info, but doesn't shrink it, as it requires a new bit
be added. This strange approach with the 'hasmacro' bit is needed
to not lose preprocessor performance.
llvm-svn: 42722
|
|
|
|
|
|
|
|
| |
number of arguments now and does the right thing, but the nullary/unary
accessors are preserved as convenience functions. This allows us to
slightly simplify clients.
llvm-svn: 42716
|
|
|
|
| |
llvm-svn: 42715
|
|
|
|
|
|
|
|
| |
Selector's instead of requiring void* to be used. I converted one use of
DenseSet<void*> over to use DenseSet<Selector> but the others should change
as well.
llvm-svn: 42645
|
|
|
|
|
|
|
|
|
|
|
| |
- Add SelectorTable, which enables us to remove MultiKeywordSelector from the public header.
- Remove FoldingSet from IdentifierInfo.h and Preprocessor.h.
- Remove Parser::ObjcGetUnarySelector and Parser::ObjcGetKeywordSelector, they are subsumed by SelectorTable.
- Add MultiKeywordSelector to IdentifierInfo.cpp.
- Move a bunch of selector related methods from ParseObjC.cpp to IdentifierInfo.cpp.
- Added some comments.
llvm-svn: 42643
|
|
|
|
|
|
| |
friend, move some methods around.
llvm-svn: 42456
|
|
|
|
|
|
|
|
|
|
|
|
| |
This motivated implementing a devious clattner inspired solution:-)
This approach uses a small value "Selector" class to point to an IdentifierInfo for the 0/1 case. For multi-keyword selectors, we instantiate a MultiKeywordSelector object (previously known as SelectorInfo). Now, the incremental cost for selectors is only 24,800 for Cocoa.h! This saves 156,592 bytes, or 86%!! The size reduction is also the result of getting rid of the AST slot, which was not strictly necessary (we will associate a selector with it's method using another table...most likely in Sema).
This change was critical to make now, before we have too many clients.
I still need to add some comments to the Selector class...will likely add later today/tomorrow.
llvm-svn: 42452
|
|
|
|
|
|
| |
reference.
llvm-svn: 42411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is SelectorInfo is not string-oriented, it is a unique aggregate of IdentifierInfo's (using a folding set). SelectorInfo also has a richer API that simplifies the parser/action interface. 3 noteworthy benefits:
#1: It is cleaner. I never "liked" storing keyword selectors (i.e. foo:bar:baz) in the IdentifierTable.
#2: It is more space efficient. Since Cocoa keyword selectors can be quite long, this technique is space saving. For Cocoa.h, pulling the keyword selectors out saves ~180k. The cost of the SelectorInfo data is ~100k. Saves ~80k, or 43%.
#3: It results in many API simplifications. Here are some highlights:
- Removed 3 actions (ActOnKeywordMessage, ActOnUnaryMessage, & one flavor of ObjcBuildMethodDeclaration that was specific to unary messages).
- Removed 3 funky structs from DeclSpec.h (ObjcKeywordMessage, ObjcKeywordDecl, and ObjcKeywordInfo).
- Removed 2 ivars and 2 constructors from ObjCMessageExpr (fyi, this space savings has not been measured).
I am happy with the way it turned out (though it took a bit more hacking than I expected). Given the central role of selectors in ObjC, making sure this is "right" will pay dividends later.
Thanks to Chris for talking this through with me and suggesting this approach.
llvm-svn: 42395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IdentifierTable.
Rationale:
We currently have a separate table to unique ObjC selectors. Since I don't need all the instance data in IdentifierInfo, I thought this would save space (and make more sense conceptually).
It turns out the cost of having duplicate entries for unary selectors (i.e. names without colons) outweighs the cost difference between the IdentifierInfo & SelectorInfo structures. Here is the data:
Two tables:
*** Selector/Identifier Stats:
# Selectors/Identifiers: 51635
Bytes allocated: 1999824
One table:
*** Identifier Table Stats:
# Identifiers: 49500
Bytes allocated: 1990316
llvm-svn: 42139
|
|
|
|
|
|
|
|
|
|
| |
- Add SelectorInfo/SelectorTable classes, modeled after IdentifierInfo/IdentifierTable.
- Add SelectorTable instance to ASTContext, created lazily through ASTContext::getSelectorInfo().
- Add SelectorInfo slot to ObjcMethodDecl.
- Add helper function to derive a SelectorInfo from ObjcKeywordInfo.
Misc: Got the Decl stats stuff up and running again...it was missing support for ObjC AST's.
llvm-svn: 42023
|
|
|
|
|
|
| |
Convert all clients to the new cleaner, more robust API.
llvm-svn: 41330
|
|
|
|
| |
llvm-svn: 40027
|
|
|
|
| |
llvm-svn: 39897
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
out of the llvm namespace. This makes the clang namespace be a sibling of
llvm instead of being a child.
The good thing about this is that it makes many things unambiguous. The
bad things is that many things in the llvm namespace (notably data structures
like smallvector) now require an llvm:: qualifier. IMO, libsystem and libsupport
should be split out of llvm into their own namespace in the future, which will fix
this issue.
llvm-svn: 39659
|
|
|
|
|
|
| |
but where we didn't warn about __attribute__.
llvm-svn: 39607
|
|
|
|
| |
llvm-svn: 39336
|
|
|
|
| |
llvm-svn: 39334
|
|
|
|
| |
llvm-svn: 39333
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
whose decl objects are lazily created the first time they are referenced.
Builtin functions are described by the clang/AST/Builtins.def file, which
makes it easy to add new ones.
This is missing two important pieces:
1. Support for the rest of the gcc builtins.
2. Support for target-specific builtins (e.g. __builtin_ia32_emms).
Just adding this builtins reduces the number of implicit function definitions
by 6, reducing the # diagnostics from 550 to 544 when parsing carbon.h.
I need to add all the i386-specific ones to eliminate several hundred more.
ugh.
llvm-svn: 39327
|
|
|
|
| |
llvm-svn: 39245
|
|
|
|
| |
llvm-svn: 39214
|
|
|
|
| |
llvm-svn: 39080
|
|
|
|
|
|
| |
libsupport. Now it can be used for other things besides identifier hashing.
llvm-svn: 39079
|
|
|
|
| |
llvm-svn: 39078
|
|
|
|
| |
llvm-svn: 39076
|
|
|
|
| |
llvm-svn: 39063
|
|
|
|
| |
llvm-svn: 39062
|
|
|
|
|
|
|
|
|
| |
chained
table. This is about 25% faster for identifier lookup. This also implements
resizing of the hash table.
llvm-svn: 39058
|
|
|
|
| |
llvm-svn: 39057
|
|
|
|
|
|
| |
This lets us find interesting properties of the hash distribution.
llvm-svn: 39056
|
|
|
|
| |
llvm-svn: 39043
|
|
|
|
| |
llvm-svn: 39038
|
|
|
|
| |
llvm-svn: 39024
|
|
|
|
| |
llvm-svn: 39014
|
|
|
|
| |
llvm-svn: 39003
|
|
|
|
|
|
| |
IdentifierTable, instead of making them resort to strcmp'ing.
llvm-svn: 39002
|
|
|
|
| |
llvm-svn: 38984
|
|
|
|
| |
llvm-svn: 38715
|
|
|
|
|
|
|
|
| |
query the hash table, when we look up an identifier that isn't at the head
of it's bucket's list, move it there. This reduces the number of list
traversals in the common case where identifiers are used in bursts.
llvm-svn: 38689
|
|
|
|
|
|
| |
enhance macro equality testing to verify argument lists match.
llvm-svn: 38682
|
|
|
|
| |
llvm-svn: 38655
|
|
|
|
| |
llvm-svn: 38650
|
|
|
|
|
|
| |
method to support iteration over all identifiers.
llvm-svn: 38628
|
|
|
|
| |
llvm-svn: 38568
|
|
llvm-svn: 38539
|