| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
vectors. Lowering explicitly avoids creating this pattern.
llvm-svn: 282360
|
|
|
|
|
|
| |
TargetRegisterInfo::getMatchingSuperReg.
llvm-svn: 282359
|
|
|
|
|
|
| |
various versions of CVTDQ2PD instruction.
llvm-svn: 282358
|
|
|
|
| |
llvm-svn: 282357
|
|
|
|
|
|
| |
hasUndefRegUpdate.
llvm-svn: 282356
|
|
|
|
|
|
| |
floating point. We can use patterns to point to the other instructions instead.
llvm-svn: 282355
|
|
|
|
| |
llvm-svn: 282352
|
|
|
|
| |
llvm-svn: 282351
|
|
|
|
| |
llvm-svn: 282350
|
|
|
|
|
|
| |
function
llvm-svn: 282349
|
|
|
|
| |
llvm-svn: 282348
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Libc++ still uses per-feature configuration macros when configuring for C++11. However libc++ requires a feature-complete C++11 compiler so there is no reason to check individual features. This patch starts the process of removing the feature specific macros and replacing their usage with `_LIBCPP_CXX03_LANG`.
This patch removes the __config macros:
* _LIBCPP_HAS_NO_TRAILING_RETURN
* _LIBCPP_HAS_NO_TEMPLATE_ALIASES
* _LIBCPP_HAS_NO_ADVANCED_SFINAE
* _LIBCPP_HAS_NO_DEFAULT_FUNCTION_TEMPLATE_ARGS
* _LIBCPP_HAS_NO_STATIC_ASSERT
As a drive I also changed our C++03 static_assert to use _Static_assert if available.
I plan to commit this without review if nobody voices an objection.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24895
llvm-svn: 282347
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds 4 new functions to StringRef, which can be used to
take or drop characters while a certain condition is met, or
until a certain condition is met. They are:
take_while - Return characters until a condition is not met.
take_until - Return characters until a condition is met.
drop_while - Remove characters until a condition is not met.
drop_until - Remove characters until a condition is met.
Internally, all of these functions delegate to two additional
helper functions which can be used to search for the position
of a character meeting or not meeting a condition, which are:
find_if - Find the first character matching a predicate.
find_if_not - Find the first character not matching a predicate.
Differential Revision: https://reviews.llvm.org/D24842
llvm-svn: 282346
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch has been a long time coming (Thanks @eugenis). It changes `_LIBCPP_INLINE_VISIBILITY` to use `__attribute__((internal_linkage))` instead of `__attribute__((visibility("hidden"), always_inline))`.
The point of `_LIBCPP_INLINE_VISIBILITY` is to prevent inline functions from being exported from both the libc++ library and from user libraries. This helps libc++ better manage it's ABI.
Previously this was done by forcing inlining and modifying the symbols visibility. However inlining isn't guaranteed and symbol visibility only affects shared libraries making this an imperfect solution. `internal_linkage` improves this situation by making all symbols local to the TU they are emitted in, regardless of inlining or visibility. IIRC the effect of applying `__attribute__((internal_linkage))` to an inline function is the same as applying `static`.
For more information about the attribute see: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
Most of the work for this patch was done by @eugenis.
Reviewers: mclow.lists, eugenis
Subscribers: eugenis, cfe-commits
Differential Revision: https://reviews.llvm.org/D24642
llvm-svn: 282345
|
|
|
|
|
|
| |
was such that if the second opcode was present the first was ingored, so we can just have one opcode.
llvm-svn: 282344
|
|
|
|
| |
llvm-svn: 282343
|
|
|
|
|
|
| |
would wait for these to be voted upon at a committee meeting (November), but the current draft standard is broken, and this should fix it. (And if it doesn't, we want to know about it soonest)
llvm-svn: 282342
|
|
|
|
|
|
|
|
| |
integer types and integer operations with floating point types. Seems isOperationLegal lies for mismatched types and operations.
Fixes PR30511.
llvm-svn: 282341
|
|
|
|
|
|
| |
because isel is not robust with multiple type profiles for the same opcode.
llvm-svn: 282340
|
|
|
|
|
|
| |
with SAE as there is no way to create the pattern.
llvm-svn: 282339
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|