llvm-svn: 62022

perform them.

 - A ToolChain is a coherent set of tools use in a compilation
   process. The idea is that a ToolChain holds roughly the information
   (specs, search paths, etc.) that is in a single gcc binary.

 - The default ToolChain is selected by the host and will generally
   correspond to what the default system compiler would do. However,
   this can be over-riden for a variety of purposes, for example the
   by the driver driver or for testing.

llvm-svn: 62021

to gcc.

llvm-svn: 62020

argument) to InputType.

llvm-svn: 62019

llvm-svn: 62018

coming from a protocol.

llvm-svn: 62017

llvm-svn: 62016

llvm-svn: 62015

that is neither a definition nor a forward declaration and where X has
not yet been declared as a tag, introduce a declaration
into the appropriate scope (which is likely *not* to be the current
scope). The rules for the placement of the declaration differ slightly
in C and C++, so we implement both and test the various corner
cases. This implementation isn't 100% correct due to some lingering
issues with the function prototype scope (for a function parameter
list) not being the same scope as the scope of the function
definition. Testcase is FIXME'd; this probably isn't an important issue.

Addresses <rdar://problem/6484805>.

llvm-svn: 62014

 - Little script for scanning a compile log and summarizing warnings,
   errors, assertions, and crashes.
 - Is very slow, and stack trace regexs probably only work on Darwin.

llvm-svn: 62013

llvm-svn: 62012

llvm-svn: 62011

Dead stores checker: Don't flag dead stores for self-assignments (common escape hatch for 'unused variable' warnings).

llvm-svn: 62010

- Refactor caching logic into a helper class PTHSpellingSearch
- Allow "random accesses" in the spelling cache, thus catching the remaining
  cases where 'getSpelling' wasn't hitting the PTH cache
  
For -Eonly, PTH, Cocoa.h:
- This reduces wall time by 3% (user time unchanged, sys time reduced)
- This reduces the amount of paged source by 1112K.
  The remaining 1112K still being paged in is from somewhere else
  (investigating).

llvm-svn: 62009

llvm-svn: 62008

in designated protocols lazily.

llvm-svn: 62007

llvm-svn: 62006

llvm-svn: 62005

llvm-svn: 62004

llvm-svn: 62003

comprehensive and can support more complex style analysis.

llvm-svn: 62002

of ScopedDecls (using the new ScopedDecl::NextDeclInScope
pointer). Performance-wise:

  - It's a net win in memory utilization, since DeclContext is now one
    pointer smaller than it used to be (std::vectors are typically 3
    pointers; we now use 2 pointers) and 
  - Parsing Cocoa.h with -fsyntax-only (with a Release-Asserts Clang)
    is about 1.9% faster than before, most likely because we no longer
    have the memory allocations and copying associated with the
    std::vector.

I'll re-enable serialization of DeclContexts once I've sorted out the
NextDeclarator/NextDeclInScope question.

llvm-svn: 62001

llvm-svn: 62000

llvm-svn: 61999

llvm-svn: 61998

llvm-svn: 61997

Always print out SourceManager stats with 'Stats' is true.  This revealed that PTH always pulls in the source pages with -fsyntax-only (investigating further).

llvm-svn: 61996

llvm-svn: 61995

filters the decls seen by decl_iterator with two criteria: the dynamic
type of the declaration and a run-time predicate described by a member
function. This simplifies EnumDecl, RecordDecl, and ObjCContainerDecl
considerably. It has no measurable performance impact.

llvm-svn: 61994

llvm-svn: 61993

crashes.

llvm-svn: 61992

llvm-svn: 61991

llvm-svn: 61990

llvm-svn: 61989

Add isa/cast/dyncast support for ObjCContainerDecl.
Renamed classprop_iterator/begin/end to prop_iterator/begin/end (the class prefix was confusing).
More simplifications to Sema::ActOnAtEnd()...
Added/changed some FIXME's as a result of the above work.

llvm-svn: 61988

llvm-svn: 61986

I noticed this in the code compiled for a routine using std::map, which produced
this code:
	%25 = tail call i32 @memcmp(i8* %24, i8* %23, i32 6) nounwind readonly
	%.lobit.i = lshr i32 %25, 31		; <i32> [#uses=1]
	%tmp.i = trunc i32 %.lobit.i to i8		; <i8> [#uses=1]
	%toBool = icmp eq i8 %tmp.i, 0		; <i1> [#uses=1]
	br i1 %toBool, label %bb3, label %bb4
which compiled to:

	call	L_memcmp$stub
	shrl	$31, %eax
	testb	%al, %al
	jne	LBB1_11	## 

with this change, we compile it to:

	call	L_memcmp$stub
	testl	%eax, %eax
	js	LBB1_11

This triggers all the time in common code, with patters like this:

	%169 = and i32 %ply, 1		; <i32> [#uses=1]
	%170 = trunc i32 %169 to i8		; <i8> [#uses=1]
	%toBool = icmp ne i8 %170, 0		; <i1> [#uses=1]

 	%7 = lshr i32 %6, 24		; <i32> [#uses=1]
	%9 = trunc i32 %7 to i8		; <i8> [#uses=1]
	%10 = icmp ne i8 %9, 0		; <i1> [#uses=1]

etc

llvm-svn: 61985

llvm-svn: 61984

jump threading can have bugs, who knew? ;-)

llvm-svn: 61983

llvm-svn: 61982