- Oct 04, 2015
-
-
Tobias Grosser authored
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
-
Simon Pilgrim authored
llvm-svn: 249263
-
Joerg Sonnenberger authored
llvm-svn: 249262
-
Igor Breger authored
Added tests for intrinsics and encoding. Differential Revision: http://reviews.llvm.org/D12690 llvm-svn: 249261
-
Craig Topper authored
llvm-svn: 249260
-
Craig Topper authored
llvm-svn: 249259
-
Craig Topper authored
llvm-svn: 249258
-
David Majnemer authored
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
-
Todd Fiala authored
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
-
Davide Italiano authored
Add tests to ensure we handle this case this case gracefully. llvm-svn: 249255
-
Davide Italiano authored
I saw these in the wild while trying to link shared libraries. llvm-svn: 249254
-
Jeroen Ketema authored
llvm-svn: 249253
-
Eric Fiselier authored
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
-
Simon Pilgrim authored
Updated the FADD combines to work with vectors as well as scalars. Differential Revision: http://reviews.llvm.org/D13416 llvm-svn: 249251
-
Sanjay Patel authored
These are based on PR25016 and likely caused by a bug in MachineCombiner's definition of improvesCriticalPathLen(). llvm-svn: 249249
-
Sanjay Patel authored
llvm-svn: 249248
-
Davide Italiano authored
llvm-svn: 249247
-
Davide Italiano authored
llvm-svn: 249246
-
Davide Italiano authored
This was the last tool relying on this pattern. llvm-svn: 249244
-
Simon Pilgrim authored
The custom lowering in LowerExtendedLoad is doing the equivalent shuffle, so make use of existing lowering code to reduce duplication. llvm-svn: 249243
-
Rafael Espindola authored
llvm-svn: 249242
-
Rafael Espindola authored
llvm-svn: 249241
-
Simon Pilgrim authored
llvm-svn: 249240
-
Tobias Grosser authored
llvm-svn: 249239
-
Tobias Grosser authored
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
-
Tobias Grosser authored
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
-
Simon Pilgrim authored
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
-
- Oct 03, 2015
-
-
Yaron Keren authored
+couple more of double-negated !SourceLocation.isInvalid() unfixed in r249228. llvm-svn: 249235
-
Ed Maste authored
This matches what bfd ld accepts. llvm-svn: 249234
-
Sean Callanan authored
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
-
Saleem Abdulrasool authored
Forgot to add the '='. In cl mode, --target must have an '='. llvm-svn: 249232
-
Kostya Serebryany authored
llvm-svn: 249231
-
Ed Maste authored
llvm-svn: 249230
-
Saleem Abdulrasool authored
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
-
Yaron Keren authored
llvm-svn: 249228
-
Saleem Abdulrasool authored
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
-
Eric Fiselier authored
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
-
Dan Gohman authored
This is a temporary assembly syntax that will likely evolve along with broader upcoming syntax changes. llvm-svn: 249225
-
Rafael Espindola authored
llvm-svn: 249224
-
NAKAMURA Takumi authored
llvm-svn: 249223
-