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

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

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

[libFuzzer] make LLVMFuzzerTestOneInput (the fuzzer target function) return int instead of void. (following llvm r249214)

llvm-svn: 249215

[libFuzzer] make LLVMFuzzerTestOneInput (the fuzzer target function) return 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

llvm-svn: 249206

I randomly came across this difference between AArch64 and other targets:
on the latter, we don't emit nil checks for known non-nil class method
calls thanks to r247350, but we still do for AArch64 stret calls.

They use different code paths, because those are special, as they go
through the regular msgSend, not the msgSend*_stret variants.

llvm-svn: 249205

llvm-svn: 249204

was terminated (e.g., due timeout).

llvm-svn: 249203

[CMake] We need to explicitly add llvm-config before clang so that LLVM_BUILD_EXTERNAL_COMPILER_RT can depend on llvm-config.

This patch is a required stepping stone to fix PR14109.

llvm-svn: 249202

llvm-svn: 249201

llvm-svn: 249200

The darwin and macho_embedded libraries get installed to different locations, so we need to feed through an INSTALL_PATH.

llvm-svn: 249199

Fix style while I'm here.

llvm-svn: 249198