| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 249258
|
| |
|
|
|
|
|
|
| |
Track which basic blocks belong to which funclets. Permit branch
folding to fire but only if it can prove that doing so will not cause
code in one funclet to be reused in another.
llvm-svn: 249257
|
| |
|
|
|
|
|
|
|
|
|
| |
When the readline target exists (only for non-Android Linux currently),
ensure that target is made a dependency of the finish_swig python-wrap-up
steps. This ensures it is built when building the lldb target.
Fixes:
https://llvm.org/bugs/show_bug.cgi?id=25038
llvm-svn: 249256
|
| |
|
|
|
|
| |
Add tests to ensure we handle this case this case gracefully.
llvm-svn: 249255
|
| |
|
|
|
|
| |
I saw these in the wild while trying to link shared libraries.
llvm-svn: 249254
|
| |
|
|
| |
llvm-svn: 249253
|
| |
|
|
|
|
|
|
|
|
|
| |
Diagnose when a pointer to const T is used as the first argument in at atomic
builtin unless that builtin is a load operation. This is already checked for
C11 atomics builtins but not for __atomic ones.
This patch was given the LGTM by rsmith when it was part
of a larger review. (See http://reviews.llvm.org/D10407)
llvm-svn: 249252
|
| |
|
|
|
|
|
|
| |
Updated the FADD combines to work with vectors as well as scalars.
Differential Revision: http://reviews.llvm.org/D13416
llvm-svn: 249251
|
| |
|
|
|
|
|
| |
These are based on PR25016 and likely caused by a bug in
MachineCombiner's definition of improvesCriticalPathLen().
llvm-svn: 249249
|
| |
|
|
| |
llvm-svn: 249248
|
| |
|
|
| |
llvm-svn: 249247
|
| |
|
|
| |
llvm-svn: 249246
|
| |
|
|
|
|
| |
This was the last tool relying on this pattern.
llvm-svn: 249244
|
| |
|
|
|
|
| |
The custom lowering in LowerExtendedLoad is doing the equivalent shuffle, so make use of existing lowering code to reduce duplication.
llvm-svn: 249243
|
| |
|
|
| |
llvm-svn: 249242
|
| |
|
|
| |
llvm-svn: 249241
|
| |
|
|
| |
llvm-svn: 249240
|
| |
|
|
| |
llvm-svn: 249239
|
| |
|
|
|
|
|
| |
By using asserting value handles, we will get assertions when we forget to clear
any of the Value maps instead of difficult to debug undefined behavior.
llvm-svn: 249238
|
| |
|
|
|
|
|
| |
By using asserting value handles, we will get assertions when we forget to clear
any of the Value maps instead of difficult to debug undefined behavior.
llvm-svn: 249237
|
| |
|
|
|
|
|
|
|
|
| |
visitSIGN_EXTEND_INREG calls SelectionDAG::getNode to constant fold scalar constants but handles vector constants itself, despite getNode being capable of dealing with them.
This required a minor change to the getNode implementation to actually deal with cases where the scalars of a BUILD_VECTOR were wider integers than the vector type - which was the only extra ability of the visitSIGN_EXTEND_INREG implementation.
No codegen intended and all existing tests remain the same.
llvm-svn: 249236
|
| |
|
|
|
|
| |
+couple more of double-negated !SourceLocation.isInvalid() unfixed in r249228.
llvm-svn: 249235
|
| |
|
|
|
|
| |
This matches what bfd ld accepts.
llvm-svn: 249234
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The concept here is that languages may have different ways of communicating
results. In particular, languages may have different names for their result
variables and in fact may have multiple types of result variables (e.g.,
error results). Materializer was tied to one specific model of result handling.
Instead, now UserExpressions can register their own handlers for the result
variables they inject. This allows language-specific code in Materializer to
be moved into the expression parser plug-in, and it simplifies Materializer.
These delegates are subclasses of PersistentVariableDelegate.
PersistentVariableDelegate can provide the name of the result variable, and is
notified when the result variable is populated. It can also be used to touch
persistent variables if need be, updating language-specific state. The
UserExpression owns the delegate and can decide on its result based on
consulting all of its (potentially multiple) delegates.
The user expression itself now makes the determination of what the final result
of the expression is, rather than relying on the Materializer, and I've added a
virtual function to UserExpression to allow this.
llvm-svn: 249233
|
| |
|
|
|
|
| |
Forgot to add the '='. In cl mode, --target must have an '='.
llvm-svn: 249232
|
| |
|
|
| |
llvm-svn: 249231
|
| |
|
|
| |
llvm-svn: 249230
|
| |
|
|
|
|
|
|
| |
The default target is ARM on the ARM self host bots. This is problematic since
the behaviour on x86, x64 is different from ARM. Explicitly pass the target.
This should hopefully fix the ARM bots.
llvm-svn: 249229
|
| |
|
|
|
|
| |
SourceLocation.isValid().
llvm-svn: 249228
|
| |
|
|
|
|
|
|
|
|
| |
The Windows on ARM ABI recommends that FPO be disabled. This is since the
Windows on ARM ABI uses the FP for fast stack walking. By paying the slight
cost of the loss of registers, a much faster backtrace is possible by using the
frame pointer since the pdata need not be consulted. Furthermore, even if pdata
is not available, you can still more easily reconstruct the stack.
llvm-svn: 249227
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently the test suite defaults to C++11 mode if no standard version is supplied to LIT using `--param=std=c++XX`. This patch changes that behavior so that the newest possible dialect is selected instead.
I have already patched the C++11 bot to explicitly specify `--param=std=c++11`. I'm just putting this up for review to see if anybody objects to this idea.
Reviewers: mclow.lists, jroelofs, danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13331
llvm-svn: 249226
|
| |
|
|
|
|
|
| |
This is a temporary assembly syntax that will likely evolve along with
broader upcoming syntax changes.
llvm-svn: 249225
|
| |
|
|
| |
llvm-svn: 249224
|
| |
|
|
|
|
| |
something. :)
llvm-svn: 249223
|
| |
|
|
|
|
|
|
| |
This time by lifting the lambda's in `createNodeFromSelectLikePHI` to
the file scope. Looks like there are differences in capture rules
between clang and MSVC?
llvm-svn: 249222
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D13395
llvm-svn: 249221
|
| |
|
|
|
|
|
| |
They are constructed without one and they can't go back, so this was
effectively dead code.
llvm-svn: 249220
|
| |
|
|
| |
llvm-svn: 249219
|
| |
|
|
| |
llvm-svn: 249218
|
| |
|
|
| |
llvm-svn: 249217
|
| |
|
|
| |
llvm-svn: 249216
|
| |
|
|
|
|
| |
int instead of void. (following llvm r249214)
llvm-svn: 249215
|
| |
|
|
|
|
| |
int instead of void. The actual return value is not *yet* used (and expected to be 0). This change is API breaking, so the fuzzers will need to be updated.
llvm-svn: 249214
|
| |
|
|
|
|
|
|
|
|
| |
Per Intel intrinsics guide:
- _mm256_stream_load_si256 takes `__m256i const *'
- _mm_stream_load_si128 takes `__m128i *', for no good reason.
Let's accept const* for both.
llvm-svn: 249213
|
| |
|
|
|
|
|
|
| |
The trailing backslashes in some ASCII art added in r248527 cause a
"error: multi-line comment [-Werror=comment]" when building with gcc
4.9.1 -Wall. Swallow (ASCII-)artistic integrity and use pipes instead.
llvm-svn: 249212
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Teach SCEV to match patterns like
```
br %cond, label %left, label %right
left:
br label %merge
right:
br label %merge
merge:
V = phi [ %x, %left ], [ %y, %right ]
```
as "select %cond, %x, %y". Before this SCEV would match PHI nodes
exclusively to add recurrences.
This addresses PR25005.
Reviewers: joker.eph, joker-eph, atrick
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13378
llvm-svn: 249211
|
| |
|
|
| |
llvm-svn: 249210
|
| |
|
|
|
|
| |
This was inadvertently re-enabled as a in r248883.
llvm-svn: 249209
|
| |
|
|
|
|
|
|
|
|
| |
TestDiamond and TestSBValueCast were due to a bug in clang. That
bug has been fixed, so xfail is removed. However fixing that bug
exposed another bug in clang, which is not yet fixed. That bug
causes one test to start crashing, and another to fail unexpectedly
so the status of those tests is updated as well.
llvm-svn: 249208
|
| |
|
|
| |
llvm-svn: 249207
|