llvm-svn: 69843

llvm-svn: 69838

llvm-svn: 69835

indicate whether or not the range represents an absolute range or should be
extended by lexing to the end of the token.

llvm-svn: 69834

llvm-svn: 69833

llvm-svn: 69831

llvm-svn: 69830

to happen (ever), but at least we'll do the right thing when it does.

llvm-svn: 69829

headers. Future approaches to (de-)serializing ASTs will be based on
the PCH infrastructure.

llvm-svn: 69828

Eliminate some FIXMEs in the PCH reader that were either already fixed or aren't actually things to fix

llvm-svn: 69827

in a bunch of declarations from the PCH file. We're down to loading
very few declarations in Carbon-prefixed "Hello, World!":

*** PCH Statistics:
  6/20693 types read (0.028995%)
  7/59230 declarations read (0.011818%)
  50/44914 identifiers read (0.111324%)
  0/32954 statements read (0.000000%)
  5/6187 macros read (0.080815%)

llvm-svn: 69825

llvm-svn: 69824

context.

llvm-svn: 69823

int.  Note that constant int->complex float and float->complex int casts
were being miscompiled.

llvm-svn: 69821

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%)

llvm-svn: 69820

llvm-svn: 69819

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%)

llvm-svn: 69815

- Remove stale assertion that was breaking the test suite.
- When popping location contexts, only add a control-flow piece for fileID
  locations.

llvm-svn: 69814

starts from the first character of the first statement.

llvm-svn: 69813

character instead of the entire range for the IfStmt, ForStmt, etc. We may
gradually refine these ranges later, but basically terminator ranges just refer
to the first keyword.

llvm-svn: 69812

Rework the shadow struct that is layed out for Objective-C classes.

 - Superclasses are now always laid out in their shadow structure at
   the first field.

 - Prior to this, the entire class heirarchy was flattened into a
   single structure which meant that alignment, padding, and bitfields
   were incorrect (the ASTRecordLayout was correct however, which
   meant our debug info didn't coincide with ivar offsets, for
   example).

 - This is still very suboptimal (for example, ivar are looked up
   recursively, but I believe the ivar layout itself is now at least
   close to correct.

 - <rdar://problem/6773388> error: objc[29823]: layout bitmap sliding
   backwards

llvm-svn: 69811

llvm-svn: 69803

ccc-analyzer: Don't create preprocessed files about the ignored 'cdecl' attribute.  We know Clang doesn't support it yet.

llvm-svn: 69802

 - This is only used by CGObjCRuntime now.

llvm-svn: 69800

declaration now.

llvm-svn: 69799

 - This has pros and cons, but for now the pros seem to significantly
   outway the con.

The con is that we will always need to cast in the runtime
implementation to a struct type, if we wish to access an interface
directly.

The pros are:
 - Avoid the cost of generating types which are used. Most
   manipulation of Objective-C objects is done through messages, and
   only the implementation of a class will directly access
   memory. Previously, we would convert the type even if it only
   appear as a function parameter, for example.

 - We don't need to worry about incomplete types, and
   UpdateCompletedType for interfaces is gone.

 - It becomes easier to narrow the interface to the shadow struct for
   Objective-C interfaces (so it can be eliminated).

Currently the runtimes still use the CodeGenTypes machinery to
generate the LLVM structure they need via ConvertTagDecl, but this can
eventually be replaced.

llvm-svn: 69797

underlying llvm::StructType for an interface.

llvm-svn: 69796

 - 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.

llvm-svn: 69794

llvm-svn: 69793

llvm-svn: 69790

llvm-svn: 69789

 - For now, this means we are always doing the address computations by
   hand instead of constructing a proper GEP. Right now, however, this
   is less important than having fewer entry points to dealing with
   Objective-C interface layout.

llvm-svn: 69787

llvm-svn: 69786

llvm-svn: 69784

llvm-svn: 69783

llvm-svn: 69782

llvm-svn: 69781

way to serialize selectors yet.

llvm-svn: 69780

fix a couple of bugs in reader support for ObjCInterfaceDecl,
and add support for reading ObjCInterfaceType.

llvm-svn: 69779

llvm-svn: 69778