| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
While collections containing nil elements can still be iterated over in an
Objective-C for-in loop, the most common Cocoa collections -- NSArray,
NSDictionary, and NSSet -- cannot contain nil elements. This checker adds
that assumption to the analyzer state.
This was the cause of some minor false positives concerning CFRelease calls
on objects in an NSArray.
llvm-svn: 158319
|
| |
|
|
|
|
|
|
|
| |
This has a small hit in the case where only one class is interesting
(NilArgChecker) but is a big improvement when looking for one of several
interesting classes (VariadicMethodTypeChecker), in which the most common
case is that there is no match.
llvm-svn: 158318
|
| |
|
|
|
|
|
| |
It found a lot of cruft in LLVM that I removed last week and I couldn't find any
false positives. Time to give it more testing.
llvm-svn: 158317
|
| |
|
|
|
|
| |
Patch by James Benton!
llvm-svn: 158316
|
| |
|
|
|
|
| |
This is necessary on Linux and supported on Darwin, see PR2604.
llvm-svn: 158315
|
| |
|
|
|
|
| |
This functionality mirrors that available on PPC/Darwin.
llvm-svn: 158314
|
| |
|
|
|
|
| |
No functional change; these will be used by upcoming scheduler enhancements.
llvm-svn: 158313
|
| |
|
|
| |
llvm-svn: 158312
|
| |
|
|
|
|
|
|
|
| |
The TableGenBackend base class doesn't do much, and will be removed
completely soon.
Patch by Sean Silva!
llvm-svn: 158311
|
| |
|
|
|
|
|
|
|
|
|
| |
This showed up the first time rend() was called on a bundled instruction
in the Mips backend.
Also avoid dereferencing end() in bundle_iterator::operator++().
We still don't have a place to put unit tests for this stuff.
llvm-svn: 158310
|
| |
|
|
|
|
|
|
|
| |
only using the linkage.
Use and test both, documenting that considering the visibility and linkage
of template parameters is a difference from gcc.
llvm-svn: 158309
|
| |
|
|
| |
llvm-svn: 158307
|
| |
|
|
| |
llvm-svn: 158306
|
| |
|
|
| |
llvm-svn: 158305
|
| |
|
|
|
|
| |
Contributed by: Yabin Hu <yabin.hwu@gmail.com>
llvm-svn: 158304
|
| |
|
|
|
|
|
|
|
| |
We turned off the CMN instruction because it had semantics which we weren't
getting correct. If we are comparing with an immediate, then it's okay to use
the CMN instruction.
<rdar://problem/7569620>
llvm-svn: 158302
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 158301
|
| |
|
|
| |
llvm-svn: 158300
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
such as "protocol" and "expression" being implicitly turned into links to
mistakenly-generated Doxygen pages:
- Escaping @ symbols when Doxygen would otherwise incorrectly interpret them;
- Escaping # symbols when they're not intended as explicit Doxygen link
requests, such as when discussing preprocessor directives;
- In one odd case, unescaping @ in @__experimental_modules_import, because
Doxygen wrote '\@' to the output in that case, causing the example in the
description of ImportDecl to be wrong; and
- Fixing a typo: @breif -> @brief.
llvm-svn: 158299
|
| |
|
|
| |
llvm-svn: 158298
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the compare.
This saves a cast, and zext is more expensive on platforms with subreg support
than trunc is. This occurs in the BSD implementation of memchr(3), see PR12750.
On the synthetic benchmark from that bug stupid_memchr and bsd_memchr have the
same performance now when not inlining either function.
stupid_memchr: 323.0us
bsd_memchr: 321.0us
memchr: 479.0us
where memchr is the llvm-gcc compiled bsd_memchr from osx lion's libc. When
inlining is enabled bsd_memchr still regresses down to llvm-gcc memchr time,
I haven't fully understood the issue yet, something is grossly mangling the
loop after inlining.
llvm-svn: 158297
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Over the entire test-suite, this has an insignificantly negative average
performance impact, but reduces some of the worst slowdowns from the
anti-dep. change (r158294).
Largest speedups:
SingleSource/Benchmarks/Stanford/Quicksort - 28%
SingleSource/Benchmarks/Stanford/Towers - 24%
SingleSource/Benchmarks/Shootout-C++/matrix - 23%
MultiSource/Benchmarks/SciMark2-C/scimark2 - 19%
MultiSource/Benchmarks/MiBench/automotive-bitcount/automotive-bitcount - 15%
(matrix and automotive-bitcount were both in the top-5 slowdown list from the
anti-dep. change)
Largest slowdowns:
MultiSource/Benchmarks/McCat/03-testtrie/testtrie - 28%
MultiSource/Benchmarks/mediabench/gsm/toast/toast - 26%
MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan - 21%
SingleSource/Benchmarks/CoyoteBench/lpbench - 20%
MultiSource/Applications/d/make_dparser - 16%
llvm-svn: 158296
|
| |
|
|
|
|
| |
Patch by Michael Kuperstein.
llvm-svn: 158295
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
register classes.
Using 'all' instead of 'critical' would be better because it would make it easier to
satisfy the bundling constraints, but, as noted in the FIXME, that is currently not
possible with the crs.
This yields an average 1% speedup over the entire test suite (on Power 7). Largest speedups:
SingleSource/Benchmarks/Shootout-C++/moments - 40%
MultiSource/Benchmarks/McCat/03-testtrie/testtrie - 28%
SingleSource/Benchmarks/BenchmarkGame/nsieve-bits - 26%
SingleSource/Benchmarks/McGill/misr - 23%
MultiSource/Applications/JM/ldecod/ldecod - 22%
Largest slowdowns:
SingleSource/Benchmarks/Shootout-C++/matrix - -29%
SingleSource/Benchmarks/Shootout-C++/ary3 - -22%
MultiSource/Benchmarks/BitBench/uuencode/uuencode - -18%
SingleSource/Benchmarks/Shootout-C++/ary - -17%
MultiSource/Benchmarks/MiBench/automotive-bitcount/automotive-bitcount - -15%
llvm-svn: 158294
|
| |
|
|
|
|
| |
consider them when enumerating builtin operator candidates.
llvm-svn: 158293
|
| |
|
|
| |
llvm-svn: 158292
|
| |
|
|
|
|
| |
instead of f128mem for integer XOP instructions.
llvm-svn: 158291
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need an efficient mechanism to determine whether a defaulted default
constructor is constexpr, in order to determine whether a class is a literal
type, so keep the incrementally-built form on CXXRecordDecl. Remove the
on-demand computation of same, so that we only have one method for determining
whether a default constructor is constexpr. This doesn't affect correctness,
since default constructor lookup is much simpler than selecting a constructor
for copying or moving.
We don't need a corresponding mechanism for defaulted copy or move constructors,
since they can't affect whether a type is a literal type. Conversely, checking
whether such functions are constexpr can require non-trivial effort, so we defer
such checks until the copy or move constructor is required.
Thus we now only compute whether a copy or move constructor is constexpr on
demand, and only compute whether a default constructor is constexpr in advance.
This is unfortunate, but seems like the best solution.
llvm-svn: 158290
|
| |
|
|
|
|
|
|
|
|
| |
an explicitly-defaulted default constructor would be constexpr. This is
necessary in weird (but well-formed) cases where a class has more than one copy
or move constructor.
Cleanup of now-unused parts of CXXRecordDecl to follow.
llvm-svn: 158289
|
| |
|
|
|
|
|
| |
initialization, and use that information to produce the right kind of
initialization during template instantiation.
llvm-svn: 158288
|
| |
|
|
| |
llvm-svn: 158287
|
| |
|
|
| |
llvm-svn: 158286
|
| |
|
|
|
|
| |
expressions.
llvm-svn: 158285
|
| |
|
|
| |
llvm-svn: 158284
|
| |
|
|
|
|
|
|
|
|
| |
The PPC64 backend had patterns for i32 <-> i64 extensions and truncations that
would leave self-moves in the final assembly. Replacing those patterns with ones
based on the SUBREG builtins yields better-looking code.
Thanks to Jakob and Owen for their suggestions in this matter.
llvm-svn: 158283
|
| |
|
|
| |
llvm-svn: 158282
|
| |
|
|
| |
llvm-svn: 158281
|
| |
|
|
|
|
| |
is_constructible. This should pull things into alignment with the final draft. Fixes http://llvm.org/bugs/show_bug.cgi?id=13063#add_comment.
llvm-svn: 158280
|
| |
|
|
|
|
| |
type. Remove the custom lowering code that selected the SDNode type.
llvm-svn: 158279
|
| |
|
|
|
|
| |
as an argument.
llvm-svn: 158278
|
| |
|
|
| |
llvm-svn: 158277
|
| |
|
|
|
|
| |
removed in r151865.
llvm-svn: 158276
|
| |
|
|
| |
llvm-svn: 158275
|
| |
|
|
|
|
| |
PathV1 implementation file.
llvm-svn: 158274
|
| |
|
|
| |
llvm-svn: 158273
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 158272
|
| |
|
|
| |
llvm-svn: 158270
|
| |
|
|
|
|
| |
BumpPtrAllocator.
llvm-svn: 158265
|
| |
|
|
|
|
| |
correlated, and thinks that cmpOp2 may be used uninitialized.
llvm-svn: 158263
|
| |
|
|
|
|
| |
internal allocator on Linux (important for TSan)
llvm-svn: 158261
|