llvm-project/clang/lib/Basic/IdentifierTable.cpp

530 lines
18 KiB
C++
Raw Normal View History

//===--- IdentifierTable.cpp - Hash table for identifier lookup -----------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file implements the IdentifierInfo, IdentifierVisitor, and
// IdentifierTable interfaces.
//
//===----------------------------------------------------------------------===//
#include "clang/Basic/IdentifierTable.h"
#include "clang/Basic/LangOptions.h"
#include "llvm/ADT/FoldingSet.h"
#include "llvm/ADT/DenseMap.h"
#include "llvm/ADT/SmallString.h"
#include "llvm/ADT/StringSwitch.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/Support/ErrorHandling.h"
#include <cctype>
#include <cstdio>
using namespace clang;
//===----------------------------------------------------------------------===//
// IdentifierInfo Implementation
//===----------------------------------------------------------------------===//
Fix: <rdar://problem/6510344> [pth] PTH slows down regular lexer considerably (when it has substantial work) Changes to IdentifierTable: - High-level summary: StringMap never owns IdentifierInfos. It just references them. - The string map now has StringMapEntry<IdentifierInfo*> instead of StringMapEntry<IdentifierInfo>. The IdentifierInfo object is allocated using the same bump pointer allocator as used by the StringMap. Changes to IdentifierInfo: - Added an extra pointer to point to the StringMapEntry<IdentifierInfo*> in the string map. This pointer will be null if the IdentifierInfo* is *only* used by the PTHLexer (that is it isn't in the StringMap). Algorithmic changes: - Non-PTH case: IdentifierInfo::get() will always consult the StringMap first to see if we have an IdentifierInfo object. If that StringMapEntry references a null pointer, we allocate a new one from the BumpPtrAllocator and update the reference in the StringMapEntry. - PTH case: We do the same lookup as with the non-PTH case, but if we don't get a hit in the StringMap we do a secondary lookup in the PTHManager for the IdentifierInfo. If we don't find an IdentifierInfo we create a new one as in the non-PTH case. If we do find and IdentifierInfo in the PTHManager, we update the StringMapEntry to refer to it so that the IdentifierInfo will be found on the next StringMap lookup. This way we only do a binary search in the PTH file at most once for a given IdentifierInfo. This greatly speeds things up for source files containing a non-trivial amount of code. Performance impact: While these changes do add some extra indirection in IdentifierTable to access an IdentifierInfo*, I saw speedups even in the non-PTH case as well. Non-PTH: For -fsyntax-only on Cocoa.h, we see a 6% speedup. PTH (with Cocoa.h in token cache): 11% speedup. I also did an experiment where we did -fsyntax-only on a source file including a large header and Cocoa.h, but the token cache did not contain the larger header. For this file, we were seeing a performance *regression* when using PTH of 3% over non-PTH. Now we are seeing a performance improvement of 9%! Tests: The serialization tests are now failing. I looked at this extensively, and I my belief is that this change is unmasking a bug rather than introducing a new one. I have disabled the serialization tests for now. llvm-svn: 62636
2009-01-21 07:28:34 +08:00
IdentifierInfo::IdentifierInfo() {
TokenID = tok::identifier;
ObjCOrBuiltinID = 0;
HasMacro = false;
IsExtension = false;
IsCXX11CompatKeyword = false;
IsPoisoned = false;
IsCPPOperatorKeyword = false;
NeedsHandleIdentifier = false;
IsFromAST = false;
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 17:33:13 +08:00
ChangedAfterLoad = false;
RevertedTokenID = false;
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 17:33:13 +08:00
OutOfDate = false;
IsModulesImport = false;
FETokenInfo = 0;
Fix: <rdar://problem/6510344> [pth] PTH slows down regular lexer considerably (when it has substantial work) Changes to IdentifierTable: - High-level summary: StringMap never owns IdentifierInfos. It just references them. - The string map now has StringMapEntry<IdentifierInfo*> instead of StringMapEntry<IdentifierInfo>. The IdentifierInfo object is allocated using the same bump pointer allocator as used by the StringMap. Changes to IdentifierInfo: - Added an extra pointer to point to the StringMapEntry<IdentifierInfo*> in the string map. This pointer will be null if the IdentifierInfo* is *only* used by the PTHLexer (that is it isn't in the StringMap). Algorithmic changes: - Non-PTH case: IdentifierInfo::get() will always consult the StringMap first to see if we have an IdentifierInfo object. If that StringMapEntry references a null pointer, we allocate a new one from the BumpPtrAllocator and update the reference in the StringMapEntry. - PTH case: We do the same lookup as with the non-PTH case, but if we don't get a hit in the StringMap we do a secondary lookup in the PTHManager for the IdentifierInfo. If we don't find an IdentifierInfo we create a new one as in the non-PTH case. If we do find and IdentifierInfo in the PTHManager, we update the StringMapEntry to refer to it so that the IdentifierInfo will be found on the next StringMap lookup. This way we only do a binary search in the PTH file at most once for a given IdentifierInfo. This greatly speeds things up for source files containing a non-trivial amount of code. Performance impact: While these changes do add some extra indirection in IdentifierTable to access an IdentifierInfo*, I saw speedups even in the non-PTH case as well. Non-PTH: For -fsyntax-only on Cocoa.h, we see a 6% speedup. PTH (with Cocoa.h in token cache): 11% speedup. I also did an experiment where we did -fsyntax-only on a source file including a large header and Cocoa.h, but the token cache did not contain the larger header. For this file, we were seeing a performance *regression* when using PTH of 3% over non-PTH. Now we are seeing a performance improvement of 9%! Tests: The serialization tests are now failing. I looked at this extensively, and I my belief is that this change is unmasking a bug rather than introducing a new one. I have disabled the serialization tests for now. llvm-svn: 62636
2009-01-21 07:28:34 +08:00
Entry = 0;
}
//===----------------------------------------------------------------------===//
// IdentifierTable Implementation
//===----------------------------------------------------------------------===//
IdentifierIterator::~IdentifierIterator() { }
IdentifierInfo: - IdentifierInfo can now (optionally) have its string data not be co-located with itself. This is for use with PTH. This aspect is a little gross, as getName() and getLength() now make assumptions about a possible alternate representation of IdentifierInfo. Perhaps we should make IdentifierInfo have virtual methods? IdentifierTable: - Added class "IdentifierInfoLookup" that can be used by IdentifierTable to perform "string -> IdentifierInfo" lookups using an auxilliary data structure. This is used by PTH. - Perform tests show that IdentifierTable::get() does not slow down because of the extra check for the IdentiferInfoLookup object (the regular StringMap lookup does enough work to mitigate the impact of an extra null pointer check). - The upshot is that now that some IdentifierInfo objects might be owned by the IdentiferInfoLookup object. This should be reviewed. PTH: - Modified PTHManager::GetIdentifierInfo to *not* insert entries in IdentifierTable's string map, and instead create IdentifierInfo objects on the fly when mapping from persistent IDs to IdentifierInfos. This saves a ton of work with string copies, hashing, and StringMap lookup and resizing. This change was motivated because when processing source files in the PTH cache we don't need to do any string -> IdentifierInfo lookups. - PTHManager now subclasses IdentifierInfoLookup, allowing clients of IdentifierTable to transparently use IdentifierInfo objects managed by the PTH file. PTHManager resolves "string -> IdentifierInfo" queries by doing a binary search over a sorted table of identifier strings in the PTH file (the exact algorithm we use can be changed as needed). These changes lead to the following performance changes when using PTH on Cocoa.h: - fsyntax-only: 10% performance improvement - Eonly: 30% performance improvement llvm-svn: 62273
2009-01-16 02:47:46 +08:00
IdentifierInfoLookup::~IdentifierInfoLookup() {}
namespace {
/// \brief A simple identifier lookup iterator that represents an
/// empty sequence of identifiers.
class EmptyLookupIterator : public IdentifierIterator
{
public:
virtual StringRef Next() { return StringRef(); }
};
}
IdentifierIterator *IdentifierInfoLookup::getIdentifiers() const {
return new EmptyLookupIterator();
}
ExternalIdentifierLookup::~ExternalIdentifierLookup() {}
IdentifierInfo: - IdentifierInfo can now (optionally) have its string data not be co-located with itself. This is for use with PTH. This aspect is a little gross, as getName() and getLength() now make assumptions about a possible alternate representation of IdentifierInfo. Perhaps we should make IdentifierInfo have virtual methods? IdentifierTable: - Added class "IdentifierInfoLookup" that can be used by IdentifierTable to perform "string -> IdentifierInfo" lookups using an auxilliary data structure. This is used by PTH. - Perform tests show that IdentifierTable::get() does not slow down because of the extra check for the IdentiferInfoLookup object (the regular StringMap lookup does enough work to mitigate the impact of an extra null pointer check). - The upshot is that now that some IdentifierInfo objects might be owned by the IdentiferInfoLookup object. This should be reviewed. PTH: - Modified PTHManager::GetIdentifierInfo to *not* insert entries in IdentifierTable's string map, and instead create IdentifierInfo objects on the fly when mapping from persistent IDs to IdentifierInfos. This saves a ton of work with string copies, hashing, and StringMap lookup and resizing. This change was motivated because when processing source files in the PTH cache we don't need to do any string -> IdentifierInfo lookups. - PTHManager now subclasses IdentifierInfoLookup, allowing clients of IdentifierTable to transparently use IdentifierInfo objects managed by the PTH file. PTHManager resolves "string -> IdentifierInfo" queries by doing a binary search over a sorted table of identifier strings in the PTH file (the exact algorithm we use can be changed as needed). These changes lead to the following performance changes when using PTH on Cocoa.h: - fsyntax-only: 10% performance improvement - Eonly: 30% performance improvement llvm-svn: 62273
2009-01-16 02:47:46 +08:00
IdentifierTable::IdentifierTable(const LangOptions &LangOpts,
IdentifierInfoLookup* externalLookup)
: HashTable(8192), // Start with space for 8K identifiers.
ExternalLookup(externalLookup) {
// Populate the identifier table with info about keywords for the current
// language.
AddKeywords(LangOpts);
// Add the '_experimental_modules_import' contextual keyword.
get("__experimental_modules_import").setModulesImport(true);
}
//===----------------------------------------------------------------------===//
// Language Keyword Implementation
//===----------------------------------------------------------------------===//
Simplify the scheme used for keywords, and change the classification scheme to be more useful. The new scheme introduces a set of categories that should be more readable, and also reflects what we want to consider as an extension more accurately. Specifically, it makes the "what is a keyword" determination accurately reflect whether the keyword is a GNU or Microsoft extension. I also introduced separate flags for keyword aliases; this is useful because the classification of the aliases is mostly unrelated to the classification of the original keyword. This patch treats anything that's in the implementation namespace (prefixed with "__", or "_X" where "X" is any upper-case letter) as a keyword without marking it as an extension. This is consistent with the standards in that an implementation is allowed to define arbitrary extensions in the implementation namespace without violating the standard. This gets rid of all the nasty "extension used" warnings for stuff like __attribute__ in -pedantic mode. We still warn for extensions outside of the the implementation namespace, like typeof. If someone wants to implement -Wextensions or something like that, we could add additional information to the keyword table. This also removes processing for the unused "Boolean" language option; such an extension isn't supported on any other C implementation, so I don't see any point to adding it. The changes to test/CodeGen/inline.c are required because previously, we weren't actually disabling the "inline" keyword in -std=c89 mode. I'll remove Boolean and NoExtensions from LangOptions in a follow-up commit. llvm-svn: 70281
2009-04-28 11:13:54 +08:00
// Constants for TokenKinds.def
namespace {
enum {
KEYC99 = 0x1,
KEYCXX = 0x2,
KEYCXX0X = 0x4,
KEYGNU = 0x8,
KEYMS = 0x10,
BOOLSUPPORT = 0x20,
KEYALTIVEC = 0x40,
KEYNOCXX = 0x80,
KEYBORLAND = 0x100,
KEYOPENCL = 0x200,
KEYC11 = 0x400,
KEYARC = 0x800,
KEYNOMS = 0x01000,
KEYALL = (0xffff & ~KEYNOMS) // Because KEYNOMS is used to exclude.
Simplify the scheme used for keywords, and change the classification scheme to be more useful. The new scheme introduces a set of categories that should be more readable, and also reflects what we want to consider as an extension more accurately. Specifically, it makes the "what is a keyword" determination accurately reflect whether the keyword is a GNU or Microsoft extension. I also introduced separate flags for keyword aliases; this is useful because the classification of the aliases is mostly unrelated to the classification of the original keyword. This patch treats anything that's in the implementation namespace (prefixed with "__", or "_X" where "X" is any upper-case letter) as a keyword without marking it as an extension. This is consistent with the standards in that an implementation is allowed to define arbitrary extensions in the implementation namespace without violating the standard. This gets rid of all the nasty "extension used" warnings for stuff like __attribute__ in -pedantic mode. We still warn for extensions outside of the the implementation namespace, like typeof. If someone wants to implement -Wextensions or something like that, we could add additional information to the keyword table. This also removes processing for the unused "Boolean" language option; such an extension isn't supported on any other C implementation, so I don't see any point to adding it. The changes to test/CodeGen/inline.c are required because previously, we weren't actually disabling the "inline" keyword in -std=c89 mode. I'll remove Boolean and NoExtensions from LangOptions in a follow-up commit. llvm-svn: 70281
2009-04-28 11:13:54 +08:00
};
}
/// AddKeyword - This method is used to associate a token ID with specific
/// identifiers because they are language keywords. This causes the lexer to
/// automatically map matching identifiers to specialized token codes.
///
/// The C90/C99/CPP/CPP0x flags are set to 3 if the token is a keyword in a
/// future language standard, set to 2 if the token should be enabled in the
/// specified language, set to 1 if it is an extension in the specified
/// language, and set to 0 if disabled in the specified language.
static void AddKeyword(StringRef Keyword,
Simplify the scheme used for keywords, and change the classification scheme to be more useful. The new scheme introduces a set of categories that should be more readable, and also reflects what we want to consider as an extension more accurately. Specifically, it makes the "what is a keyword" determination accurately reflect whether the keyword is a GNU or Microsoft extension. I also introduced separate flags for keyword aliases; this is useful because the classification of the aliases is mostly unrelated to the classification of the original keyword. This patch treats anything that's in the implementation namespace (prefixed with "__", or "_X" where "X" is any upper-case letter) as a keyword without marking it as an extension. This is consistent with the standards in that an implementation is allowed to define arbitrary extensions in the implementation namespace without violating the standard. This gets rid of all the nasty "extension used" warnings for stuff like __attribute__ in -pedantic mode. We still warn for extensions outside of the the implementation namespace, like typeof. If someone wants to implement -Wextensions or something like that, we could add additional information to the keyword table. This also removes processing for the unused "Boolean" language option; such an extension isn't supported on any other C implementation, so I don't see any point to adding it. The changes to test/CodeGen/inline.c are required because previously, we weren't actually disabling the "inline" keyword in -std=c89 mode. I'll remove Boolean and NoExtensions from LangOptions in a follow-up commit. llvm-svn: 70281
2009-04-28 11:13:54 +08:00
tok::TokenKind TokenCode, unsigned Flags,
const LangOptions &LangOpts, IdentifierTable &Table) {
Simplify the scheme used for keywords, and change the classification scheme to be more useful. The new scheme introduces a set of categories that should be more readable, and also reflects what we want to consider as an extension more accurately. Specifically, it makes the "what is a keyword" determination accurately reflect whether the keyword is a GNU or Microsoft extension. I also introduced separate flags for keyword aliases; this is useful because the classification of the aliases is mostly unrelated to the classification of the original keyword. This patch treats anything that's in the implementation namespace (prefixed with "__", or "_X" where "X" is any upper-case letter) as a keyword without marking it as an extension. This is consistent with the standards in that an implementation is allowed to define arbitrary extensions in the implementation namespace without violating the standard. This gets rid of all the nasty "extension used" warnings for stuff like __attribute__ in -pedantic mode. We still warn for extensions outside of the the implementation namespace, like typeof. If someone wants to implement -Wextensions or something like that, we could add additional information to the keyword table. This also removes processing for the unused "Boolean" language option; such an extension isn't supported on any other C implementation, so I don't see any point to adding it. The changes to test/CodeGen/inline.c are required because previously, we weren't actually disabling the "inline" keyword in -std=c89 mode. I'll remove Boolean and NoExtensions from LangOptions in a follow-up commit. llvm-svn: 70281
2009-04-28 11:13:54 +08:00
unsigned AddResult = 0;
if (Flags == KEYALL) AddResult = 2;
Simplify the scheme used for keywords, and change the classification scheme to be more useful. The new scheme introduces a set of categories that should be more readable, and also reflects what we want to consider as an extension more accurately. Specifically, it makes the "what is a keyword" determination accurately reflect whether the keyword is a GNU or Microsoft extension. I also introduced separate flags for keyword aliases; this is useful because the classification of the aliases is mostly unrelated to the classification of the original keyword. This patch treats anything that's in the implementation namespace (prefixed with "__", or "_X" where "X" is any upper-case letter) as a keyword without marking it as an extension. This is consistent with the standards in that an implementation is allowed to define arbitrary extensions in the implementation namespace without violating the standard. This gets rid of all the nasty "extension used" warnings for stuff like __attribute__ in -pedantic mode. We still warn for extensions outside of the the implementation namespace, like typeof. If someone wants to implement -Wextensions or something like that, we could add additional information to the keyword table. This also removes processing for the unused "Boolean" language option; such an extension isn't supported on any other C implementation, so I don't see any point to adding it. The changes to test/CodeGen/inline.c are required because previously, we weren't actually disabling the "inline" keyword in -std=c89 mode. I'll remove Boolean and NoExtensions from LangOptions in a follow-up commit. llvm-svn: 70281
2009-04-28 11:13:54 +08:00
else if (LangOpts.CPlusPlus && (Flags & KEYCXX)) AddResult = 2;
else if (LangOpts.CPlusPlus0x && (Flags & KEYCXX0X)) AddResult = 2;
else if (LangOpts.C99 && (Flags & KEYC99)) AddResult = 2;
else if (LangOpts.GNUKeywords && (Flags & KEYGNU)) AddResult = 1;
else if (LangOpts.MicrosoftExt && (Flags & KEYMS)) AddResult = 1;
else if (LangOpts.Borland && (Flags & KEYBORLAND)) AddResult = 1;
else if (LangOpts.Bool && (Flags & BOOLSUPPORT)) AddResult = 2;
else if (LangOpts.AltiVec && (Flags & KEYALTIVEC)) AddResult = 2;
else if (LangOpts.OpenCL && (Flags & KEYOPENCL)) AddResult = 2;
else if (!LangOpts.CPlusPlus && (Flags & KEYNOCXX)) AddResult = 2;
else if (LangOpts.C11 && (Flags & KEYC11)) AddResult = 2;
// We treat bridge casts as objective-C keywords so we can warn on them
// in non-arc mode.
else if (LangOpts.ObjC2 && (Flags & KEYARC)) AddResult = 2;
else if (LangOpts.CPlusPlus && (Flags & KEYCXX0X)) AddResult = 3;
// Don't add this keyword under MicrosoftMode.
if (LangOpts.MicrosoftMode && (Flags & KEYNOMS))
return;
Simplify the scheme used for keywords, and change the classification scheme to be more useful. The new scheme introduces a set of categories that should be more readable, and also reflects what we want to consider as an extension more accurately. Specifically, it makes the "what is a keyword" determination accurately reflect whether the keyword is a GNU or Microsoft extension. I also introduced separate flags for keyword aliases; this is useful because the classification of the aliases is mostly unrelated to the classification of the original keyword. This patch treats anything that's in the implementation namespace (prefixed with "__", or "_X" where "X" is any upper-case letter) as a keyword without marking it as an extension. This is consistent with the standards in that an implementation is allowed to define arbitrary extensions in the implementation namespace without violating the standard. This gets rid of all the nasty "extension used" warnings for stuff like __attribute__ in -pedantic mode. We still warn for extensions outside of the the implementation namespace, like typeof. If someone wants to implement -Wextensions or something like that, we could add additional information to the keyword table. This also removes processing for the unused "Boolean" language option; such an extension isn't supported on any other C implementation, so I don't see any point to adding it. The changes to test/CodeGen/inline.c are required because previously, we weren't actually disabling the "inline" keyword in -std=c89 mode. I'll remove Boolean and NoExtensions from LangOptions in a follow-up commit. llvm-svn: 70281
2009-04-28 11:13:54 +08:00
// Don't add this keyword if disabled in this language.
if (AddResult == 0) return;
IdentifierInfo &Info =
Table.get(Keyword, AddResult == 3 ? tok::identifier : TokenCode);
Simplify the scheme used for keywords, and change the classification scheme to be more useful. The new scheme introduces a set of categories that should be more readable, and also reflects what we want to consider as an extension more accurately. Specifically, it makes the "what is a keyword" determination accurately reflect whether the keyword is a GNU or Microsoft extension. I also introduced separate flags for keyword aliases; this is useful because the classification of the aliases is mostly unrelated to the classification of the original keyword. This patch treats anything that's in the implementation namespace (prefixed with "__", or "_X" where "X" is any upper-case letter) as a keyword without marking it as an extension. This is consistent with the standards in that an implementation is allowed to define arbitrary extensions in the implementation namespace without violating the standard. This gets rid of all the nasty "extension used" warnings for stuff like __attribute__ in -pedantic mode. We still warn for extensions outside of the the implementation namespace, like typeof. If someone wants to implement -Wextensions or something like that, we could add additional information to the keyword table. This also removes processing for the unused "Boolean" language option; such an extension isn't supported on any other C implementation, so I don't see any point to adding it. The changes to test/CodeGen/inline.c are required because previously, we weren't actually disabling the "inline" keyword in -std=c89 mode. I'll remove Boolean and NoExtensions from LangOptions in a follow-up commit. llvm-svn: 70281
2009-04-28 11:13:54 +08:00
Info.setIsExtensionToken(AddResult == 1);
Info.setIsCXX11CompatKeyword(AddResult == 3);
}
/// AddCXXOperatorKeyword - Register a C++ operator keyword alternative
/// representations.
static void AddCXXOperatorKeyword(StringRef Keyword,
tok::TokenKind TokenCode,
IdentifierTable &Table) {
IdentifierInfo &Info = Table.get(Keyword, TokenCode);
Info.setIsCPlusPlusOperatorKeyword();
}
/// AddObjCKeyword - Register an Objective-C \@keyword like "class" "selector"
/// or "property".
static void AddObjCKeyword(StringRef Name,
tok::ObjCKeywordKind ObjCID,
IdentifierTable &Table) {
Table.get(Name).setObjCKeywordID(ObjCID);
}
/// AddKeywords - Add all keywords to the symbol table.
///
void IdentifierTable::AddKeywords(const LangOptions &LangOpts) {
// Add keywords and tokens for the current language.
#define KEYWORD(NAME, FLAGS) \
AddKeyword(StringRef(#NAME), tok::kw_ ## NAME, \
Simplify the scheme used for keywords, and change the classification scheme to be more useful. The new scheme introduces a set of categories that should be more readable, and also reflects what we want to consider as an extension more accurately. Specifically, it makes the "what is a keyword" determination accurately reflect whether the keyword is a GNU or Microsoft extension. I also introduced separate flags for keyword aliases; this is useful because the classification of the aliases is mostly unrelated to the classification of the original keyword. This patch treats anything that's in the implementation namespace (prefixed with "__", or "_X" where "X" is any upper-case letter) as a keyword without marking it as an extension. This is consistent with the standards in that an implementation is allowed to define arbitrary extensions in the implementation namespace without violating the standard. This gets rid of all the nasty "extension used" warnings for stuff like __attribute__ in -pedantic mode. We still warn for extensions outside of the the implementation namespace, like typeof. If someone wants to implement -Wextensions or something like that, we could add additional information to the keyword table. This also removes processing for the unused "Boolean" language option; such an extension isn't supported on any other C implementation, so I don't see any point to adding it. The changes to test/CodeGen/inline.c are required because previously, we weren't actually disabling the "inline" keyword in -std=c89 mode. I'll remove Boolean and NoExtensions from LangOptions in a follow-up commit. llvm-svn: 70281
2009-04-28 11:13:54 +08:00
FLAGS, LangOpts, *this);
#define ALIAS(NAME, TOK, FLAGS) \
AddKeyword(StringRef(NAME), tok::kw_ ## TOK, \
Simplify the scheme used for keywords, and change the classification scheme to be more useful. The new scheme introduces a set of categories that should be more readable, and also reflects what we want to consider as an extension more accurately. Specifically, it makes the "what is a keyword" determination accurately reflect whether the keyword is a GNU or Microsoft extension. I also introduced separate flags for keyword aliases; this is useful because the classification of the aliases is mostly unrelated to the classification of the original keyword. This patch treats anything that's in the implementation namespace (prefixed with "__", or "_X" where "X" is any upper-case letter) as a keyword without marking it as an extension. This is consistent with the standards in that an implementation is allowed to define arbitrary extensions in the implementation namespace without violating the standard. This gets rid of all the nasty "extension used" warnings for stuff like __attribute__ in -pedantic mode. We still warn for extensions outside of the the implementation namespace, like typeof. If someone wants to implement -Wextensions or something like that, we could add additional information to the keyword table. This also removes processing for the unused "Boolean" language option; such an extension isn't supported on any other C implementation, so I don't see any point to adding it. The changes to test/CodeGen/inline.c are required because previously, we weren't actually disabling the "inline" keyword in -std=c89 mode. I'll remove Boolean and NoExtensions from LangOptions in a follow-up commit. llvm-svn: 70281
2009-04-28 11:13:54 +08:00
FLAGS, LangOpts, *this);
#define CXX_KEYWORD_OPERATOR(NAME, ALIAS) \
if (LangOpts.CXXOperatorNames) \
AddCXXOperatorKeyword(StringRef(#NAME), tok::ALIAS, *this);
#define OBJC1_AT_KEYWORD(NAME) \
if (LangOpts.ObjC1) \
AddObjCKeyword(StringRef(#NAME), tok::objc_##NAME, *this);
#define OBJC2_AT_KEYWORD(NAME) \
if (LangOpts.ObjC2) \
AddObjCKeyword(StringRef(#NAME), tok::objc_##NAME, *this);
#define TESTING_KEYWORD(NAME, FLAGS)
#include "clang/Basic/TokenKinds.def"
if (LangOpts.ParseUnknownAnytype)
AddKeyword("__unknown_anytype", tok::kw___unknown_anytype, KEYALL,
LangOpts, *this);
}
tok::PPKeywordKind IdentifierInfo::getPPKeywordID() const {
// We use a perfect hash function here involving the length of the keyword,
// the first and third character. For preprocessor ID's there are no
// collisions (if there were, the switch below would complain about duplicate
// case values). Note that this depends on 'if' being null terminated.
#define HASH(LEN, FIRST, THIRD) \
(LEN << 5) + (((FIRST-'a') + (THIRD-'a')) & 31)
#define CASE(LEN, FIRST, THIRD, NAME) \
case HASH(LEN, FIRST, THIRD): \
return memcmp(Name, #NAME, LEN) ? tok::pp_not_keyword : tok::pp_ ## NAME
unsigned Len = getLength();
if (Len < 2) return tok::pp_not_keyword;
const char *Name = getNameStart();
switch (HASH(Len, Name[0], Name[2])) {
default: return tok::pp_not_keyword;
CASE( 2, 'i', '\0', if);
CASE( 4, 'e', 'i', elif);
CASE( 4, 'e', 's', else);
CASE( 4, 'l', 'n', line);
CASE( 4, 's', 'c', sccs);
CASE( 5, 'e', 'd', endif);
CASE( 5, 'e', 'r', error);
CASE( 5, 'i', 'e', ident);
CASE( 5, 'i', 'd', ifdef);
CASE( 5, 'u', 'd', undef);
CASE( 6, 'a', 's', assert);
CASE( 6, 'd', 'f', define);
CASE( 6, 'i', 'n', ifndef);
CASE( 6, 'i', 'p', import);
CASE( 6, 'p', 'a', pragma);
CASE( 7, 'd', 'f', defined);
CASE( 7, 'i', 'c', include);
CASE( 7, 'w', 'r', warning);
CASE( 8, 'u', 'a', unassert);
CASE(12, 'i', 'c', include_next);
CASE(14, '_', 'p', __public_macro);
CASE(15, '_', 'p', __private_macro);
CASE(16, '_', 'i', __include_macros);
#undef CASE
#undef HASH
}
}
//===----------------------------------------------------------------------===//
// Stats Implementation
//===----------------------------------------------------------------------===//
/// PrintStats - Print statistics about how well the identifier table is doing
/// at hashing identifiers.
void IdentifierTable::PrintStats() const {
unsigned NumBuckets = HashTable.getNumBuckets();
unsigned NumIdentifiers = HashTable.getNumItems();
unsigned NumEmptyBuckets = NumBuckets-NumIdentifiers;
unsigned AverageIdentifierSize = 0;
unsigned MaxIdentifierLength = 0;
// TODO: Figure out maximum times an identifier had to probe for -stats.
Fix: <rdar://problem/6510344> [pth] PTH slows down regular lexer considerably (when it has substantial work) Changes to IdentifierTable: - High-level summary: StringMap never owns IdentifierInfos. It just references them. - The string map now has StringMapEntry<IdentifierInfo*> instead of StringMapEntry<IdentifierInfo>. The IdentifierInfo object is allocated using the same bump pointer allocator as used by the StringMap. Changes to IdentifierInfo: - Added an extra pointer to point to the StringMapEntry<IdentifierInfo*> in the string map. This pointer will be null if the IdentifierInfo* is *only* used by the PTHLexer (that is it isn't in the StringMap). Algorithmic changes: - Non-PTH case: IdentifierInfo::get() will always consult the StringMap first to see if we have an IdentifierInfo object. If that StringMapEntry references a null pointer, we allocate a new one from the BumpPtrAllocator and update the reference in the StringMapEntry. - PTH case: We do the same lookup as with the non-PTH case, but if we don't get a hit in the StringMap we do a secondary lookup in the PTHManager for the IdentifierInfo. If we don't find an IdentifierInfo we create a new one as in the non-PTH case. If we do find and IdentifierInfo in the PTHManager, we update the StringMapEntry to refer to it so that the IdentifierInfo will be found on the next StringMap lookup. This way we only do a binary search in the PTH file at most once for a given IdentifierInfo. This greatly speeds things up for source files containing a non-trivial amount of code. Performance impact: While these changes do add some extra indirection in IdentifierTable to access an IdentifierInfo*, I saw speedups even in the non-PTH case as well. Non-PTH: For -fsyntax-only on Cocoa.h, we see a 6% speedup. PTH (with Cocoa.h in token cache): 11% speedup. I also did an experiment where we did -fsyntax-only on a source file including a large header and Cocoa.h, but the token cache did not contain the larger header. For this file, we were seeing a performance *regression* when using PTH of 3% over non-PTH. Now we are seeing a performance improvement of 9%! Tests: The serialization tests are now failing. I looked at this extensively, and I my belief is that this change is unmasking a bug rather than introducing a new one. I have disabled the serialization tests for now. llvm-svn: 62636
2009-01-21 07:28:34 +08:00
for (llvm::StringMap<IdentifierInfo*, llvm::BumpPtrAllocator>::const_iterator
I = HashTable.begin(), E = HashTable.end(); I != E; ++I) {
unsigned IdLen = I->getKeyLength();
AverageIdentifierSize += IdLen;
if (MaxIdentifierLength < IdLen)
MaxIdentifierLength = IdLen;
}
fprintf(stderr, "\n*** Identifier Table Stats:\n");
fprintf(stderr, "# Identifiers: %d\n", NumIdentifiers);
fprintf(stderr, "# Empty Buckets: %d\n", NumEmptyBuckets);
fprintf(stderr, "Hash density (#identifiers per bucket): %f\n",
NumIdentifiers/(double)NumBuckets);
fprintf(stderr, "Ave identifier length: %f\n",
(AverageIdentifierSize/(double)NumIdentifiers));
fprintf(stderr, "Max identifier length: %d\n", MaxIdentifierLength);
// Compute statistics about the memory allocated for identifiers.
HashTable.getAllocator().PrintStats();
}
//===----------------------------------------------------------------------===//
// SelectorTable Implementation
//===----------------------------------------------------------------------===//
unsigned llvm::DenseMapInfo<clang::Selector>::getHashValue(clang::Selector S) {
return DenseMapInfo<void*>::getHashValue(S.getAsOpaquePtr());
}
namespace clang {
/// MultiKeywordSelector - One of these variable length records is kept for each
/// selector containing more than one keyword. We use a folding set
/// to unique aggregate names (keyword selectors in ObjC parlance). Access to
/// this class is provided strictly through Selector.
class MultiKeywordSelector
: public DeclarationNameExtra, public llvm::FoldingSetNode {
MultiKeywordSelector(unsigned nKeys) {
ExtraKindOrNumArgs = NUM_EXTRA_KINDS + nKeys;
}
public:
// Constructor for keyword selectors.
MultiKeywordSelector(unsigned nKeys, IdentifierInfo **IIV) {
assert((nKeys > 1) && "not a multi-keyword selector");
ExtraKindOrNumArgs = NUM_EXTRA_KINDS + nKeys;
// Fill in the trailing keyword array.
IdentifierInfo **KeyInfo = reinterpret_cast<IdentifierInfo **>(this+1);
for (unsigned i = 0; i != nKeys; ++i)
KeyInfo[i] = IIV[i];
}
// getName - Derive the full selector name and return it.
std::string getName() const;
unsigned getNumArgs() const { return ExtraKindOrNumArgs - NUM_EXTRA_KINDS; }
typedef IdentifierInfo *const *keyword_iterator;
keyword_iterator keyword_begin() const {
return reinterpret_cast<keyword_iterator>(this+1);
}
keyword_iterator keyword_end() const {
return keyword_begin()+getNumArgs();
}
IdentifierInfo *getIdentifierInfoForSlot(unsigned i) const {
assert(i < getNumArgs() && "getIdentifierInfoForSlot(): illegal index");
return keyword_begin()[i];
}
static void Profile(llvm::FoldingSetNodeID &ID,
keyword_iterator ArgTys, unsigned NumArgs) {
ID.AddInteger(NumArgs);
for (unsigned i = 0; i != NumArgs; ++i)
ID.AddPointer(ArgTys[i]);
}
void Profile(llvm::FoldingSetNodeID &ID) {
Profile(ID, keyword_begin(), getNumArgs());
}
};
} // end namespace clang.
unsigned Selector::getNumArgs() const {
unsigned IIF = getIdentifierInfoFlag();
if (IIF <= ZeroArg)
return 0;
if (IIF == OneArg)
return 1;
// We point to a MultiKeywordSelector.
MultiKeywordSelector *SI = getMultiKeywordSelector();
return SI->getNumArgs();
}
IdentifierInfo *Selector::getIdentifierInfoForSlot(unsigned argIndex) const {
if (getIdentifierInfoFlag() < MultiArg) {
assert(argIndex == 0 && "illegal keyword index");
return getAsIdentifierInfo();
}
// We point to a MultiKeywordSelector.
MultiKeywordSelector *SI = getMultiKeywordSelector();
return SI->getIdentifierInfoForSlot(argIndex);
}
StringRef Selector::getNameForSlot(unsigned int argIndex) const {
IdentifierInfo *II = getIdentifierInfoForSlot(argIndex);
return II? II->getName() : StringRef();
}
std::string MultiKeywordSelector::getName() const {
SmallString<256> Str;
llvm::raw_svector_ostream OS(Str);
for (keyword_iterator I = keyword_begin(), E = keyword_end(); I != E; ++I) {
if (*I)
OS << (*I)->getName();
OS << ':';
}
return OS.str();
}
std::string Selector::getAsString() const {
if (InfoPtr == 0)
return "<null selector>";
if (getIdentifierInfoFlag() < MultiArg) {
IdentifierInfo *II = getAsIdentifierInfo();
// If the number of arguments is 0 then II is guaranteed to not be null.
if (getNumArgs() == 0)
return II->getName();
if (!II)
return ":";
return II->getName().str() + ":";
}
// We have a multiple keyword selector.
return getMultiKeywordSelector()->getName();
}
/// Interpreting the given string using the normal CamelCase
/// conventions, determine whether the given string starts with the
/// given "word", which is assumed to end in a lowercase letter.
static bool startsWithWord(StringRef name, StringRef word) {
if (name.size() < word.size()) return false;
return ((name.size() == word.size() ||
!islower(name[word.size()]))
&& name.startswith(word));
}
ObjCMethodFamily Selector::getMethodFamilyImpl(Selector sel) {
IdentifierInfo *first = sel.getIdentifierInfoForSlot(0);
if (!first) return OMF_None;
StringRef name = first->getName();
if (sel.isUnarySelector()) {
if (name == "autorelease") return OMF_autorelease;
if (name == "dealloc") return OMF_dealloc;
if (name == "finalize") return OMF_finalize;
if (name == "release") return OMF_release;
if (name == "retain") return OMF_retain;
if (name == "retainCount") return OMF_retainCount;
if (name == "self") return OMF_self;
}
if (name == "performSelector") return OMF_performSelector;
// The other method families may begin with a prefix of underscores.
while (!name.empty() && name.front() == '_')
name = name.substr(1);
if (name.empty()) return OMF_None;
switch (name.front()) {
case 'a':
if (startsWithWord(name, "alloc")) return OMF_alloc;
break;
case 'c':
if (startsWithWord(name, "copy")) return OMF_copy;
break;
case 'i':
if (startsWithWord(name, "init")) return OMF_init;
break;
case 'm':
if (startsWithWord(name, "mutableCopy")) return OMF_mutableCopy;
break;
case 'n':
if (startsWithWord(name, "new")) return OMF_new;
break;
default:
break;
}
return OMF_None;
}
namespace {
struct SelectorTableImpl {
llvm::FoldingSet<MultiKeywordSelector> Table;
llvm::BumpPtrAllocator Allocator;
};
} // end anonymous namespace.
static SelectorTableImpl &getSelectorTableImpl(void *P) {
return *static_cast<SelectorTableImpl*>(P);
}
/*static*/ Selector
SelectorTable::constructSetterName(IdentifierTable &Idents,
SelectorTable &SelTable,
const IdentifierInfo *Name) {
SmallString<100> SelectorName;
SelectorName = "set";
SelectorName += Name->getName();
SelectorName[3] = toupper(SelectorName[3]);
IdentifierInfo *SetterName = &Idents.get(SelectorName);
return SelTable.getUnarySelector(SetterName);
}
size_t SelectorTable::getTotalMemory() const {
SelectorTableImpl &SelTabImpl = getSelectorTableImpl(Impl);
return SelTabImpl.Allocator.getTotalMemory();
}
Selector SelectorTable::getSelector(unsigned nKeys, IdentifierInfo **IIV) {
if (nKeys < 2)
return Selector(IIV[0], nKeys);
SelectorTableImpl &SelTabImpl = getSelectorTableImpl(Impl);
// Unique selector, to guarantee there is one per name.
llvm::FoldingSetNodeID ID;
MultiKeywordSelector::Profile(ID, IIV, nKeys);
void *InsertPos = 0;
if (MultiKeywordSelector *SI =
SelTabImpl.Table.FindNodeOrInsertPos(ID, InsertPos))
return Selector(SI);
// MultiKeywordSelector objects are not allocated with new because they have a
// variable size array (for parameter types) at the end of them.
unsigned Size = sizeof(MultiKeywordSelector) + nKeys*sizeof(IdentifierInfo *);
MultiKeywordSelector *SI =
(MultiKeywordSelector*)SelTabImpl.Allocator.Allocate(Size,
llvm::alignOf<MultiKeywordSelector>());
new (SI) MultiKeywordSelector(nKeys, IIV);
SelTabImpl.Table.InsertNode(SI, InsertPos);
return Selector(SI);
}
SelectorTable::SelectorTable() {
Impl = new SelectorTableImpl();
}
SelectorTable::~SelectorTable() {
delete &getSelectorTableImpl(Impl);
}
const char *clang::getOperatorSpelling(OverloadedOperatorKind Operator) {
switch (Operator) {
case OO_None:
case NUM_OVERLOADED_OPERATORS:
return 0;
#define OVERLOADED_OPERATOR(Name,Spelling,Token,Unary,Binary,MemberOnly) \
case OO_##Name: return Spelling;
#include "clang/Basic/OperatorKinds.def"
}
llvm_unreachable("Invalid OverloadedOperatorKind!");
}