By using AssertingVH we will see assertions in case Values to which still
pointers in our maps exists are deleted. This is very useful as we previously
had some bugs that were caused by such stale Value pointers.

llvm-svn: 249267

The use of const qualified Value pointers prevents the use of AssertingVH. We
could probably think of adding const support to AssertingVH, but as const
correctness seems to currently provide limited benefit in Polly, we do not do
this yet.

llvm-svn: 249266

llvm-svn: 249265

There have been various places where llvm::DenseMap<const llvm::Value *,
llvm::Value *> types have been defined, but all types have been expected to be
identical. We make this more clear by consolidating the different types and use
BlockGenerator::ValueMapT wherever there is a need for types to match
BlockGenerator::ValueMapT.

llvm-svn: 249264

llvm-svn: 249263

llvm-svn: 249262

Added tests for intrinsics and encoding.

Differential Revision: http://reviews.llvm.org/D12690

llvm-svn: 249261

llvm-svn: 249260

llvm-svn: 249259

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

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