up to the checker yet, but essentially it allows a user to specify that an
Objective-C method or C function returns an owned an Objective-C object.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70001 91177308-0d34-0410-b5e6-96231b3b80d8
(1) Make sure to pad on-disk hash tables with 4 bytes, not 2, since
the reader assumes that bucket data is aligned on 4-byte
boundaries.
(2) Don't emit the number of factory methods twice. This was
throwing off the data counts and therefore causing lookups to
fail. I've added asserts so that this class of error cannot happen
again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69991 91177308-0d34-0410-b5e6-96231b3b80d8
pools, combined). The methods in the global method pool are lazily
loaded from an on-disk hash table when Sema looks into its version of
the hash tables.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69989 91177308-0d34-0410-b5e6-96231b3b80d8
As part of this, make ObjCImplDecl inherit from NamedDecl (since
ObjCImplementationDecls now need to have names so that they can be
found). This brings ObjCImplDecl very, very close to
ObjCContainerDecl; we may be able to merge them soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69941 91177308-0d34-0410-b5e6-96231b3b80d8
their own namespace (IDNS_Protocol) and use the normal name-lookup
routines to find them. Aside from the simplification this provides
(one less DenseMap!), it means that protocols will be lazily
deserialized from PCH files.
Make the code size of the selector table block match the code size of
the type and decl blocks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69939 91177308-0d34-0410-b5e6-96231b3b80d8
SEL, Class, Protocol, CFConstantString, and
__objcFastEnumerationState. With this, we can now run the Objective-C
methods and properties PCH tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69932 91177308-0d34-0410-b5e6-96231b3b80d8
This enables class recognition to work with PCH. I believe this means we can remove Sema::ObjCInterfaceDecls and it's usage within Sema::LookupName(). Will investigate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69891 91177308-0d34-0410-b5e6-96231b3b80d8
DeclContext rather than in a separate list. This makes PCH
(de-)serialization trivial, so that ivars can be loaded lazily.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69857 91177308-0d34-0410-b5e6-96231b3b80d8
indicate whether or not the range represents an absolute range or should be
extended by lexing to the end of the token.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69834 91177308-0d34-0410-b5e6-96231b3b80d8
file needs to store. CodeGen needs to see these definitions (via
HandleTopLevelDecl), otherwise it won't be able to generate code for
them.
This patch notifies the consumer (e.g., CodeGen) about function
definitions and variable definitions when the corresponding
declarations are deserialized. Hence, we don't eagerly deserialize the
declarations for every variable or function that has a definition in
the PCH file. This gives another 5% speedup for the Carbon-prefixed
"Hello, World!", and brings our PCH statistics down to something far
more reasonable:
*** PCH Statistics:
13/20693 types read (0.062823%)
17/59230 declarations read (0.028702%)
54/44914 identifiers read (0.120230%)
0/32954 statements read (0.000000%)
5/6187 macros read (0.080815%)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69820 91177308-0d34-0410-b5e6-96231b3b80d8
PCH files now contain complete information about builtins, including
any declarations that have been synthesized as part of building the
PCH file. When using a PCH file, we do not initialize builtins at all;
when needed, they'll be found in the PCH file.
This optimization translations into a 9% speedup for "Hello, World!"
with Carbon.h as a prefix header and roughly a 5% speedup for 403.gcc
with its prefix header. We're also reading less of the PCH file for
"Hello, World!":
*** PCH Statistics:
286/20693 types read (1.382110%)
1630/59230 declarations read (2.751984%)
764/44914 identifiers read (1.701029%)
1/32954 statements read (0.003035%)
5/6187 macros read (0.080815%)
down from
*** PCH Statistics:
411/20693 types read (1.986179%)
2553/59230 declarations read (4.310316%)
1093/44646 identifiers read (2.448148%)
1/32954 statements read (0.003035%)
21/6187 macros read (0.339421%)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69815 91177308-0d34-0410-b5e6-96231b3b80d8
- If we don't find a file looking relative to the current working
directory, fall back to header search. This is closer to what would
happen if the lookup was starting from right directory in the first
place (except it will find files in the directory of the main
source file, which I *think* should not be found).
- PR3992.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69794 91177308-0d34-0410-b5e6-96231b3b80d8
fix a couple of bugs in reader support for ObjCInterfaceDecl,
and add support for reading ObjCInterfaceType.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69779 91177308-0d34-0410-b5e6-96231b3b80d8
by marking the predefines buffer as a system header. The problem
with stdint is that it was getting problems like this:
/Volumes/Projects/cvs/llvm/Debug/lib/clang/1.0/include/stdint.h:43:9: warning: 'long long' is an extension when C99 mode is not enabled
typedef __INT64_TYPE__ int64_t;
^
<built-in>:73:29: note: instantiated from:
#define __INT64_TYPE__ long long
^
We correctly silence warnings in system headers, but only if the
spelling location of the token came from the system header. This is
designed so that if you use a system macro in your code that you don't
get punished for its definition. This is all cool except that the
predefines buffer wasn't considered a system header.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69770 91177308-0d34-0410-b5e6-96231b3b80d8
This optimization improves performance on the Carbon-prefixed "Hello,
World!" example by 57%. For reference, we're now about 2.25x faster
than GCC PCH. We're also pulling in far less of the PCH file:
*** PCH Statistics:
411/20693 types read (1.986179%)
2553/59230 declarations read (4.310316%)
1093/44646 identifiers read (2.448148%)
1/32954 statements read (0.003035%)
21/6187 macros read (0.339421%)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69755 91177308-0d34-0410-b5e6-96231b3b80d8
unit into the PCH file, since we won't be performing name lookup into
it anyway. Reduces the size of the Carbon.h PCH file by ~200k.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69739 91177308-0d34-0410-b5e6-96231b3b80d8
identifiers from a precompiled header.
This patch changes the primary name lookup method for entities within
a precompiled header. Previously, we would load all of the names of
declarations at translation unit scope into a large DenseMap (inside
the TranslationUnitDecl's DeclContext), and then perform a special
"last resort" lookup into this DeclContext when we knew there was a
PCH file (see Sema::LookupName). Now, when we see an identifier named
for the first time, we load all of the declarations with that name
that are visible from the translation unit into the IdentifierInfo's
chain of declarations. Thus, the explicit "look into the translation
unit's DeclContext" code is gone, and Sema effectively uses the same
IdentifierInfo-based name lookup mechanism whether we are using a PCH
file or not.
This approach should help PCH scale with the size of the input program
rather than the size of the PCH file. The "Hello, World!" application
with Carbon.h as a PCH file now loads 20% of the identifiers in the
PCH file rather than 85% of the identifiers.
90% of the 20% of identifiers loaded are actually loaded when we
deserialize the preprocessor state. The next step is to make the
preprocessor load macros lazily, which should drastically reduce the
number of types, declarations, and identifiers loaded for "Hello,
World".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69737 91177308-0d34-0410-b5e6-96231b3b80d8
Once selector support is in place, we should be able to take this for a spin (and add test cases).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69674 91177308-0d34-0410-b5e6-96231b3b80d8
that also includes the contents of the IdentifierInfo itself (the
various fields and flags, along with the chain of identifiers visible
at the top level that have that name).
We don't make any use of the hash table yet, except that our
identifier ID -> string mapping points into the hash table now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69625 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Ted Kremenek
Steve Naroff
Daniel Dunbar
Chris Lattner