| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop looking at users of UndefValue and ConstantPointerNull in the
objective C ARC optimizers. The other users aren't actually
interesting, since they're not pointing at a particular object. I
imagine these calls could be optimized through -instcombine... maybe
they already are?
These early returns will be required at some point in the future, with a
WIP patch that asserts when someone accesses a use-list on ConstantData.
llvm-svn: 282338
|
|
|
|
|
|
|
|
|
| |
There is no benefit in looking through assumptions on UndefValue to
guess known bits. Return early to avoid walking their use-lists, and
assert that all instances of ConstantData are handled here for similar
reasons (UndefValue was the only integer/pointer holdout).
llvm-svn: 282337
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug was introduced with:
http://reviews.llvm.org/rL272511
We need to restrict the lowering to v4f32 comparisons because that's all SSE1 can handle.
This should fix:
https://llvm.org/bugs/show_bug.cgi?id=28044
llvm-svn: 282336
|
|
|
|
|
|
|
|
| |
I found out this wasn't tested when looking at Vedant's coverage bot
numbers, so, thanks to him. While I'm here, switch the error message
to be lld-compliant (first letter lowercase).
llvm-svn: 282335
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assumptions on UndefValue and ConstantPointerNull aren't relevant to
other users. Ignore them entirely to avoid wasting cycles walking
through their (possibly extremely extensive (cross-module)) use-lists.
It wasn't clear how to add a specific test for this, and it'll be
covered anyway by an eventual patch that asserts when trying to access
the use-list of an instance of ConstantData.
llvm-svn: 282334
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check and return early for ConstantPointerNull and UndefValue
specifically in isKnownNonNullAt, and assert that ConstantData never
make it to isKnownNonNullFromDominatingCondition.
This confirms that isKnownNonNullFromDominatingCondition never walks
through the use-list of an instance of ConstantData. Given that such
use-lists cross module boundaries, it never really made sense to do so,
and was potentially very expensive.
llvm-svn: 282333
|
|
|
|
| |
llvm-svn: 282332
|
|
|
|
|
|
| |
tests for is_error_code and is_error_condition, since they were really lacking. Thanks to Alisdair for the heads-up that we were missing these.
llvm-svn: 282331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When having
``` c++
#define MACRO code-with-warning
MACRO; // NOLINT
```
clang-tidy would still show the warning, because
it searched for "NOLINT" only in the first line,
not on the second.
This caused e.g. https://llvm.org/bugs/show_bug.cgi?id=29089
(where the macro was defined in a system header). See also
the added test cases.
Now clang-tidy looks at the line of macro invocation and every line
of macro definition for a NOLINT comment.
Reviewers: alexfh, aaron.ballman, hokein
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24845
llvm-svn: 282330
|
|
|
|
|
|
| |
It was changed recently, and was breaking compilation of the backend.
llvm-svn: 282329
|
|
|
|
|
|
|
|
|
| |
Visual Studio 2013 and onward have all the required functions in their
CRT headers, and we don't support older versions anymore.
Differential Revision: https://reviews.llvm.org/D24879
llvm-svn: 282328
|
|
|
|
|
|
|
| |
This makes it obvious that items in those maps behave like statically
created objects.
llvm-svn: 282327
|
|
|
|
|
|
|
|
|
|
| |
This adds a comment explaining why we will duplicate PartialMapping to
represent the breakdown for complex mappings (mappings with more than
one partial mapping), instead of using an array of pointer.
NFC
llvm-svn: 282326
|
|
|
|
|
|
|
| |
Like partial mappings, as we move toward TableGen'ed information, the
number should reach zero eventually.
llvm-svn: 282325
|
|
|
|
|
|
|
|
| |
This is a step toward statically allocate ValueMapping. Like the
previous few commits, the goal is to move toward a TableGen'ed like
structure with no dynamic allocation at all.
llvm-svn: 282324
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were using the address of the unique instance of a partial
mapping in the related map to access this instance. However, when the
map grows, the whole set of instances may be moved elsewhere and the
previous addresses are not valid anymore.
Instead, keep the address of the unique heap allocated instance of a
partial mapping.
Note: I did not see any actual bugs for that problem as the number of
partial mappings dynamically allocated is small (<= 4).
llvm-svn: 282323
|
|
|
|
|
|
|
|
|
|
|
| |
This diff reorders the fields of the class RedeclarableResult
to remove excessive padding.
Test plan: make -j8 check-clang
Differential revision: https://reviews.llvm.org/D24754
llvm-svn: 282322
|
|
|
|
| |
llvm-svn: 282321
|
|
|
|
|
|
|
|
|
|
|
|
| |
Return early from llvm::isSafeToDestroyConstant() whenever the value
`isa<ConstantData>()`. These constants are shared across the
LLVMContext. We never really want to delete them here, and walking
their use-lists can be very expensive.
(This is motivated by an eventual goal of removing use-lists entirely
from ConstantData.)
llvm-svn: 282320
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24881
llvm-svn: 282319
|
|
|
|
|
|
|
|
|
|
|
| |
This diff reorders the fields of ObjCCategoriesVisitor
to remove excessive padding.
Test plan: make -j8 check-clang
Differential revision: https://reviews.llvm.org/D24753
llvm-svn: 282318
|
|
|
|
| |
llvm-svn: 282317
|
|
|
|
|
|
| |
and collecting their features.
llvm-svn: 282316
|
|
|
|
|
|
| |
This test is very flaky on PPC64 (both BE and LE), but not on other platforms.
llvm-svn: 282315
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This alters the generation of LLDB_REVISION to be heavily based on how clang generates its version header. There are two benefits of this aproach.
(1) The LLDB_REVISION is generated at build time, so it will be updated after an SCM pull/update even if CMake doesn't re-run
(2) This works on Windows
As noted this code is a simplified implementation of the code from clang.
Reviewers: tfiala, zturner
Subscribers: beanz, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D24846
llvm-svn: 282314
|
|
|
|
| |
llvm-svn: 282313
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar to:
https://reviews.llvm.org/rL279958
By not prematurely lowering to loads, we should be able to more easily eliminate
the 'or' with zero instructions seen in copysign-constant-magnitude.ll.
We should also be able to extend this code to handle vectors.
llvm-svn: 282312
|
|
|
|
| |
llvm-svn: 282311
|
|
|
|
| |
llvm-svn: 282310
|
|
|
|
|
|
|
| |
This was in some code that was #ifdef'd out on Windows, so I
didn't see it.
llvm-svn: 282309
|
|
|
|
|
|
|
| |
This should fix the android build in this bot:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-buildserver/builds/11143
llvm-svn: 282308
|
|
|
|
| |
llvm-svn: 282307
|
|
|
|
| |
llvm-svn: 282306
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24882
llvm-svn: 282305
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r282294. It breaks a Linux bot:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/12180
It looks like the test checks that __llvm_profile_set_filename() alters the raw
profile filename in both the dylib and the main program. Now that
lprofCurFilename is hidden, this can't work, and we get two profiles (one for
the call to "main" and one for "func").
Back this change out so that we don't affect external users.
llvm-svn: 282304
|
|
|
|
|
|
|
|
| |
These directives are already supported by GNU assembler.
Differential Revision: https://reviews.llvm.org/D24740
llvm-svn: 282303
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23089
llvm-svn: 282302
|
|
|
|
| |
llvm-svn: 282301
|
|
|
|
|
|
|
|
| |
These data and text symbols were missing annotations for building with hidden
visibility. As we do not currently enable hidden visibility by default, this is
a NFC for the buildbots.
llvm-svn: 282300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The NativeObjectOutput class has a design problem: it mixes up the caching
policy with the interface for output streams, which makes the client-side
code hard to follow and would for example make it harder to replace the
cache implementation in an arbitrary client.
This change separates the two aspects by moving the caching policy
to a separate field in Config, replacing NativeObjectOutput with a
NativeObjectStream class which only deals with streams and does not need to
be overridden by most clients and introducing an AddFile callback for adding
files (e.g. from the cache) to the link.
Differential Revision: https://reviews.llvm.org/D24622
llvm-svn: 282299
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The current implementation of the test suite allows the user to run
a certain subset of tests using '-p', but does not allow the inverse,
where a user wants to run all but some number of known failing tests.
Implement this functionality.
Reviewers: labath, zturner, tfiala
Subscribers: jingham, sas, lldb-commits
Differential Revision: https://reviews.llvm.org/D24629
llvm-svn: 282298
|
|
|
|
| |
llvm-svn: 282297
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D24875
llvm-svn: 282296
|
|
|
|
|
|
| |
Fixes pr30465.
llvm-svn: 282295
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24885
llvm-svn: 282294
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The class BodyFarm creates bodies for
OSAtomicCompareAndSwap*, objc_atomicCompareAndSwap*, dispatch_sync*, dispatch_once*
and for them the flag isBodyAutosynthesized is set to true.
This diff
1. makes AnalysisConsumer::HandleCode skip the autosynthesized code
2. replaces assert(LCtx->getParent()) in RetainCountChecker::checkEndFunction
by assert(!LCtx->inTopFrame()) (minor cleanup)
Test plan: make -j8 check-clang-analysis
Differential revision: https://reviews.llvm.org/D24792
llvm-svn: 282293
|
|
|
|
|
|
| |
real-life code: add a script to build RE2 at a revision that has known bugs
llvm-svn: 282292
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently, a linker option must be used to control the backend
parallelism of ThinLTO. The linker option varies depending on the
linker (e.g. gold vs ld64). Add a new clang option -flto-jobs=N
to control this.
I've added in the wiring to pass this to the gold plugin. I also
added in the logic to pass this down in the form I understand that
ld64 uses on MacOS, for the darwin target.
Reviewers: mehdi_amini, dexonsmith
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D24826
llvm-svn: 282291
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As suggested in D24826, use different options for ThinLTO backend
parallelism from the option controlling regular LTO code gen
parallelism. They are already split in the LTO API, and this enables
controlling them with different clang options.
Reviewers: pcc, mehdi_amini
Subscribers: dexonsmith, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D24873
llvm-svn: 282290
|
|
|
|
|
|
|
|
| |
default"
This reverts commit r282259, as it broke the AArch64 test-suite bots.
llvm-svn: 282289
|