| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
rdar://problem/6486133
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
their lexical context
llvm-svn: 61998
|
| |
|
|
| |
llvm-svn: 61997
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 61981
|
| |
|
|
| |
llvm-svn: 61980
|
| |
|
|
|
|
| |
just llc.
llvm-svn: 61979
|
| |
|
|
| |
llvm-svn: 61978
|
| |
|
|
| |
llvm-svn: 61977
|
| |
|
|
|
|
| |
(which is constant time and cheap) before checking hasAllZeroIndices.
llvm-svn: 61976
|
| |
|
|
| |
llvm-svn: 61975
|
| |
|
|
|
|
| |
matches llvm-gcc (?).
llvm-svn: 61974
|
| |
|
|
| |
llvm-svn: 61973
|
| |
|
|
| |
llvm-svn: 61972
|
| |
|
|
|
|
|
| |
the same formatting as their corresponding SSE2 instructions, for
consistency.
llvm-svn: 61971
|