| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
The error was reported by gcc-4.3.0 during compilation.
llvm-svn: 61896
|
| |
|
|
| |
llvm-svn: 61895
|
| |
|
|
|
|
| |
StoreManager::GetRegionSVal.
llvm-svn: 61894
|
| |
|
|
| |
llvm-svn: 61893
|
| |
|
|
| |
llvm-svn: 61891
|
| |
|
|
| |
llvm-svn: 61890
|
| |
|
|
|
|
| |
functionality change.
llvm-svn: 61888
|
| |
|
|
| |
llvm-svn: 61886
|
| |
|
|
|
|
| |
member references, e.g., for anonymous struct/unions or implicit 'this' in member functions
llvm-svn: 61885
|
| |
|
|
|
|
|
|
|
| |
* Fixed {copy,assignment} constructor test names
* s/EXPECT_EQ(true, ...)/ASSERT_TRUE(...)/
Patch by Talin.
llvm-svn: 61883
|
| |
|
|
|
|
| |
of category implementation is undeclared. Issue error instead.
llvm-svn: 61882
|
| |
|
|
|
|
|
| |
method on 'super' receiver in a category implementation.
Other simpler cases were working by accident.
llvm-svn: 61880
|
| |
|
|
| |
llvm-svn: 61879
|
| |
|
|
|
|
|
|
|
| |
Duplicate-member checking within classes is still a little messy, and
anonymous unions are still completely broken in C. We'll need to unify
the handling of fields in C and C++ to make this code applicable in
both languages.
llvm-svn: 61878
|
| |
|
|
|
|
|
|
|
|
| |
was it not very helpful, it was also wrong! The problem
is shown in the testcase: the alloca might be passed to
a nocapture callee which dereferences it and returns the
original pointer. But because it was a nocapture call we
think we don't need to track its uses, but we do.
llvm-svn: 61876
|
| |
|
|
|
|
| |
Based on a bug report by Yonggang Luo.
llvm-svn: 61875
|
| |
|
|
| |
llvm-svn: 61873
|
| |
|
|
| |
llvm-svn: 61872
|
| |
|
|
|
|
|
| |
"fake" options, allowing Tools to be oblivious to whether an argument
is real or synthetic. This kills off DerivedArg & a number of FIXMEs.
llvm-svn: 61871
|
| |
|
|
| |
llvm-svn: 61870
|
| |
|
|
|
|
|
| |
instances; this just complicated things and doesn't seem to provide
any benefit.
llvm-svn: 61869
|
| |
|
|
|
|
| |
Add ObjCContainerDecl class and have ObjCInterfaceDecl/ObjCCategoryDecl/ObjCProtocolDecl inherit from it.
llvm-svn: 61866
|
| |
|
|
|
|
| |
through transparent contexts
llvm-svn: 61861
|
| |
|
|
| |
llvm-svn: 61860
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer to a (transitive) bitcast the alloca and if that integer
has the full size of the alloca, then it clobbers the whole thing.
Handle this by extracting pieces out of the stored integer and
filing them away in the SROA'd elements.
This triggers fairly frequently because the CFE uses integers to
pass small structs by value and the inliner exposes these. For
example, in kimwitu++, I see a bunch of these with i64 stores to
"%struct.std::pair<std::_Rb_tree_const_iterator<kc::impl_abstract_phylum*>,bool>"
In 176.gcc I see a few i32 stores to "%struct..0anon".
In the testcase, this is a difference between compiling test1 to:
_test1:
subl $12, %esp
movl 20(%esp), %eax
movl %eax, 4(%esp)
movl 16(%esp), %eax
movl %eax, (%esp)
movl (%esp), %eax
addl 4(%esp), %eax
addl $12, %esp
ret
vs:
_test1:
movl 8(%esp), %eax
addl 4(%esp), %eax
ret
The second half of this will be to handle loads of the same form.
llvm-svn: 61853
|
| |
|
|
| |
llvm-svn: 61852
|
| |
|
|
|
|
| |
change.
llvm-svn: 61851
|
| |
|
|
|
|
| |
requerying it all over the place.
llvm-svn: 61850
|
| |
|
|
|
|
| |
code, no functionality change.
llvm-svn: 61849
|
| |
|
|
|
|
|
| |
out its lookup context (to see through linkage
specifications). Addresses <rdar://problem/6477142>.
llvm-svn: 61848
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
any of the physical register's sub-register live intervals overlaps with the virtual register. This is overly conservative. It prevents a extract_subreg from being coalesced away:
v1024 = EDI // not killed
=
= EDI
One possible solution is for the coalescer to examine the sub-register live intervals in the same manner as the physical register. Another possibility is to examine defs and uses (when needed) of sub-registers. Both solutions are too expensive. For now, look for "short virtual intervals" and scan instructions to look for conflict instead.
This is a small win on x86-64. e.g. It shaves 403.gcc by ~80 instructions.
llvm-svn: 61847
|
| |
|
|
|
|
| |
(for killing off DerivedArg).
llvm-svn: 61846
|
| |
|
|
| |
llvm-svn: 61845
|
| |
|
|
|
|
| |
the ArgList.
llvm-svn: 61844
|
| |
|
|
| |
llvm-svn: 61843
|
| |
|
|
|
|
|
| |
into their left operand, rather than their right. Do this
by commuting the operands and inverting the condition.
llvm-svn: 61842
|
| |
|
|
| |
llvm-svn: 61841
|
| |
|
|
|
|
|
|
|
|
|
|
| |
structures and classes) in C++. Covers name lookup and the synthesis
and member access for the unnamed objects/fields associated with
anonymous unions.
Some C++ semantic checks are still missing (anonymous unions can't
have function members, static data members, etc.), and there is no
support for anonymous structs or unions in C.
llvm-svn: 61840
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
recent discussions with Thomas Clement and Ken Ferry concerning the "fundamental
rule" for Cocoa memory management
(http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html).
Here is the revised behavior of the checker concerning tracking retain/release
counts for objects returned from message expressions involving instance methods:
1) Track the returned object if the return type of the message expression is
id<..>, id, or a pointer to *any* object that subclasses NSObject. Such objects
are assumed to have a retain count. Previously the checker only tracked objects
when the receiver of the message expression was part of the standard Cocoa API
(i.e., had class names prefixed with 'NS'). This should significantly expand the
amount of checking performed.
2) Consider the object owned if the selector of the message expression contains
"alloc", "new", or "copy". Previously we also considered "create", but this
doesn't follow from the fundamental rule (discussions with the Cocoa folks
confirms this).
llvm-svn: 61837
|
| |
|
|
| |
llvm-svn: 61836
|
| |
|
|
|
|
| |
X86_COND_B and X86_COND_AE, respectively.
llvm-svn: 61835
|
| |
|
|
|
|
|
|
| |
to handle LLVMMatchType intrinsic parameters, and by adding new subclasses
of LLVMMatchType to match vector types with integral elements that are
either twice as wide or half as wide as the elements of the matched type.
llvm-svn: 61834
|
| |
|
|
| |
llvm-svn: 61833
|
| |
|
|
|
|
| |
nested in the translation unit. This fixes <rdar://problem/6476070>.
llvm-svn: 61832
|
| |
|
|
|
|
|
|
| |
avoid the need for spilling, add a new testcase that tests that the
pcmpeqd used for V_SETALLONES is changed to a constant-pool load as
needed.
llvm-svn: 61831
|
| |
|
|
|
|
|
|
|
|
|
|
| |
converted to LEA64_32r in x86's convertToThreeAddress. This
replaces code like this:
movl %esi, %edi
inc %edi
with this:
lea 1(%rsi), %edi
which appears to be beneficial.
llvm-svn: 61830
|
| |
|
|
|
|
|
| |
- Add preliminary support for v2i32; load/store generates the right code but
there's a lot work to be done to make this vector type operational.
llvm-svn: 61829
|
| |
|
|
|
|
|
|
| |
aggregate types. Don't increment the current index after reaching
the end of a struct, as it will already be pointing at
one-past-the end. This fixes PR3288.
llvm-svn: 61828
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Big Idea:
Source files are now mmaped when ContentCache::getBuffer() is first called.
While this doesn't change the functionality when lexing regular source files,
it can result in source files not being paged in when using PTH.
- Performance change:
- No observable difference (-fsyntax-only/-Eonly) on Cocoa.h when doing
regular source lexing.
- No observable time difference (-fsyntax-only/-Eonly) on Cocoa.h when using
PTH. We do observe, however, a reduction of 279K in memory mapped source
code (3% reduction). The majority of pages from Cocoa.h (and friends) are
still being pulled in, however, because any literal will cause
Preprocessor::getSpelling() to be called (causing the source for the file to
get pulled in). The next possible optimization is to cache literal strings
in the PTH file to avoid the need for the original header sources entirely.
- Right now there is a preprocessor directive to toggle between "lazy" and
"eager" creation of MemBuffers. This is not permanent, and is there in the
short term to just test additional optimizations.
llvm-svn: 61827
|
| |
|
|
|
|
| |
would be called after a SourceManager was 'cleared', so it printed bogus results. Moreover, these stats are already printed earlier in the code path.
llvm-svn: 61825
|