- 25 Feb, 2015 1 commit
-
-
Hans Wennborg authored
Filip Pizlo pointed out that this changes the C API. It's too late in the release process to figure out how we want to handle this. Reverting the patch is essentially a way of buying time: we don't change the API at the source level for now, we're not trying to fix it with a last-minute patch with a risk of unintended effects, and we preserve our options for fixing this in 3.6.1. This is not ideal, but I think it's the best compromise at this stage. llvm-svn: 230431
-
- 24 Feb, 2015 5 commits
-
-
Hans Wennborg authored
llvm-svn: 230350
-
Hans Wennborg authored
llvm-svn: 230346
-
Mark Heffernan authored
llvm-svn: 230294
-
Hans Wennborg authored
llvm-svn: 230287
-
Hal Finkel authored
llvm-svn: 230284
-
- 23 Feb, 2015 3 commits
-
-
Hal Finkel authored
llvm-svn: 230282
-
Hal Finkel authored
llvm-svn: 230281
-
Hans Wennborg authored
llvm-svn: 230277
-
- 20 Feb, 2015 3 commits
-
-
Rafael Espindola authored
llvm-svn: 229946
-
Hans Wennborg authored
llvm-svn: 229943
-
Richard Smith authored
llvm-svn: 229939
-
- 19 Feb, 2015 3 commits
-
-
Reid Kleckner authored
llvm-svn: 229874
-
Reid Kleckner authored
llvm-svn: 229873
-
Peter Collingbourne authored
llvm-svn: 229800
-
- 18 Feb, 2015 5 commits
-
-
Hans Wennborg authored
```--------------------------------------------------------------------- r229731 | sanjoy | 2015-02-18 11:32:25 -0800 (Wed, 18 Feb 2015) | 10 lines Partial fix for bug 22589 Don't spend the entire iteration space in the scalar loop prologue if computing the trip count overflows. This change also gets rid of the backedge check in the prologue loop and the extra check for overflowing trip-count. Differential Revision: http://reviews.llvm.org/D7715 ``` --------------------------------------------------------------------- llvm-svn: 229757
-
Hans Wennborg authored
```--------------------------------------------------------------------- r229719 | d0k | 2015-02-18 10:45:54 -0800 (Wed, 18 Feb 2015) | 8 lines Driver: Fix use of dangling std::string temporary What's going on here is that the ternary operator produces a std::string rvalue that the StringRef points to. I'd hoped bugs like this were a thing of the past with our asan testing but apparently this code path is only used when LLVM is configured with a custom --with-c-include-dirs setting. Unbreaks bootstrapping with GCC5 on Fedora (PR22625), patch by Jonathan Wakely! ``` --------------------------------------------------------------------- llvm-svn: 229746
-
Hans Wennborg authored
llvm-svn: 229713
-
Hans Wennborg authored
llvm-svn: 229712
-
Hans Wennborg authored
llvm-svn: 229711
-
- 17 Feb, 2015 9 commits
-
-
Hans Wennborg authored
```--------------------------------------------------------------------- r229352 | majnemer | 2015-02-15 20:02:09 -0800 (Sun, 15 Feb 2015) | 8 lines IR: Properly return nullptr when getAggregateElement is out-of-bounds We didn't properly handle the out-of-bounds case for ConstantAggregateZero and UndefValue. This would manifest as a crash when the constant folder was asked to fold a load of a constant global whose struct type has no operands. This fixes PR22595. ``` --------------------------------------------------------------------- llvm-svn: 229588
-
Hans Wennborg authored
llvm-svn: 229576
-
Hans Wennborg authored
```--------------------------------------------------------------------- r229529 | rnk | 2015-02-17 12:02:34 -0800 (Tue, 17 Feb 2015) | 8 lines Expose LLVM_VERSION_PATCH in llvm-config.h There was no reason to keep this private in config.h, and users requested that it be available in PR22615. Also fix a bug where patch versions of '0' would cause the macro to remain undefined. The "#cmakedefine" command only creates a macro if the named variable would be considered true in the context of an if(). ``` --------------------------------------------------------------------- llvm-svn: 229567
-
Hans Wennborg authored
```--------------------------------------------------------------------- r229495 | delena | 2015-02-17 05:10:05 -0800 (Tue, 17 Feb 2015) | 8 lines Fixed a bug in store sinking. The problem was in store-sink barrier check. Store sink barrier should be checked for ModRef (read-write) mode. http://llvm.org/bugs/show_bug.cgi?id=22613 ``` --------------------------------------------------------------------- llvm-svn: 229564
-
Hans Wennborg authored
```--------------------------------------------------------------------- r226808 | delena | 2015-01-22 04:07:59 -0800 (Thu, 22 Jan 2015) | 10 lines Fixed a bug in type legalizer for masked load/store intrinsics. The problem occurs when after vectorization we have type <2 x i32>. This type is promoted to <2 x i64> and then requires additional efforts for expanding loads and truncating stores. I added EXPAND / TRUNCATE attributes to the masked load/store SDNodes. The code now contains additional shuffles. I've prepared changes in the cost estimation for masked memory operations, it will be submitted separately. ``` --------------------------------------------------------------------- llvm-svn: 229561
-
Hans Wennborg authored
```--------------------------------------------------------------------- r226791 | delena | 2015-01-22 00:20:06 -0800 (Thu, 22 Jan 2015) | 7 lines Fixed a bug in masked load/store in reversed loop. Added a test. The bug was submitted to bugzilla: http://llvm.org/bugs/show_bug.cgi?id=22225 ``` --------------------------------------------------------------------- llvm-svn: 229555
-
Hans Wennborg authored
```--------------------------------------------------------------------- r229343 | lhames | 2015-02-15 15:22:43 -0800 (Sun, 15 Feb 2015) | 6 lines [ExecutionEngine] Fix dependence issue by moving RTDyldMemoryManager into RuntimeDyld. This should fix http://llvm.org/PR22593. ``` --------------------------------------------------------------------- r229351 | chapuni | 2015-02-15 18:13:30 -0800 (Sun, 15 Feb 2015) | 1 line [CMake] Add RuntimeDyld to libdeps corresponding to r229343. llvm-svn: 229553
-
Hans Wennborg authored
```--------------------------------------------------------------------- r229408 | spatel | 2015-02-16 09:26:51 -0800 (Mon, 16 Feb 2015) | 10 lines x86-64 ABI: unwrap single element structs / arrays of 256-bit vectors to pass and return in registers This is a patch for PR22563 ( http://llvm.org/bugs/show_bug.cgi?id=22563 ). We were not correctly unwrapping a single 256-bit AVX vector that was defined as an array of 1 inside a struct. We would generate a <4 x float> param/return value instead of <8 x float> and lose half of the vector. Differential Revision: http://reviews.llvm.org/D7614 ``` --------------------------------------------------------------------- llvm-svn: 229546
-
Hans Wennborg authored
```--------------------------------------------------------------------- r229421 | dexonsmith | 2015-02-16 11:18:01 -0800 (Mon, 16 Feb 2015) | 33 lines Bitcode: Fix major regression: large files w/ debug info The metadata/value split introduced a major regression reading large bitcode files that contain debug info (or other cyclic (non-self reference) metadata graphs). For the first time in a while, I dropped from libLTO.dylib down to `llvm-lto` with a non-trivial bitcode file (~350MB), and I hit this when reading the result of ld64's `-save-temps` in `llvm-lto`. Here's pseudo-code for what was going on: read-main-metadata-block: for each md: if has-fwd-ref: // Only true for cyclic graphs. any-fwd-refs <- true if any-fwd-refs: foreach md: resolve-cycles(md) // Handle cycles. foreach function: read-function-metadata-block: // Such as !alias, !loop if any-fwd-refs: foreach md: // (all metadata, not just this block) resolve-cycles(md) // A no-op, but the loop is expensive!! This commit resets the `AnyFwdRefs` flag to `false`. This on its own was enough to change my Release+Asserts `llvm-lto` time for reading this bitcode from over 20 minutes (I gave up on it) to 20 seconds. I've gone further by tracking the min/max metadata forward-references in a metadata block. This protects against a schema that has lots of functions that each reference their own metadata cycle. Unfortunately, this regression is in the 3.6 branch as well. ``` --------------------------------------------------------------------- llvm-svn: 229545
-
- 16 Feb, 2015 1 commit
-
-
Kai Nacke authored
llvm-svn: 229418
-
- 14 Feb, 2015 1 commit
-
-
Josh Klontz authored
llvm-svn: 229259
-
- 13 Feb, 2015 2 commits
-
-
Tobias Grosser authored
This reverts commit 6f02dfa802f92ee81f95ef55bf1e376a741a59fd (r225464). This commit has a couple of problems which we do not want to have in the 3.6 release. Reported-by: Geoff Nixon llvm-svn: 229086
-
Hans Wennborg authored
```--------------------------------------------------------------------- r229029 | chandlerc | 2015-02-12 18:30:01 -0800 (Thu, 12 Feb 2015) | 16 lines [IC] Fix a bug with the instcombine canonicalizing of loads and propagating of metadata. We were propagating !nonnull metadata even when the newly formed load is no longer of a pointer type. This is clearly broken and results in LLVM failing the verifier and aborting. This patch just restricts the propagation of !nonnull metadata to when we actually have a pointer type. This bug report and the initial version of this patch was provided by Charles Davis! Many thanks for finding this! We still need to add logic to round-trip the metadata correctly if we combine from pointer types to integer types and then back by using range metadata for the integer type loads. But this is the minimal and safe version of the patch, which is important so we can backport it into 3.6. ``` --------------------------------------------------------------------- llvm-svn: 229036
-
- 12 Feb, 2015 7 commits
-
-
Hans Wennborg authored
```--------------------------------------------------------------------- r228969 | hfinkel | 2015-02-12 14:43:52 -0800 (Thu, 12 Feb 2015) | 7 lines [SDAG] Don't try to use FP_EXTEND/FP_ROUND for int<->fp promotions The PowerPC backend has long promoted some floating-point vector operations (such as select) to integer vector operations. Unfortunately, this behavior was broken by r216555. When using FP_EXTEND/FP_ROUND for promotions, we must check that both the old and new types are floating-point types. Otherwise, we must use BITCAST as we did prior to r216555 for everything. ``` --------------------------------------------------------------------- llvm-svn: 228986
-
Hans Wennborg authored
```--------------------------------------------------------------------- r226616 | adrian | 2015-01-20 14:37:25 -0800 (Tue, 20 Jan 2015) | 2 lines DebugLocs without a scope should fail the verification. Follow-up to r226588. ``` --------------------------------------------------------------------- llvm-svn: 228985
-
Hans Wennborg authored
```--------------------------------------------------------------------- r226588 | adrian | 2015-01-20 10:03:37 -0800 (Tue, 20 Jan 2015) | 1 line Add an assertion and prefer a crash over an infinite loop. ``` --------------------------------------------------------------------- llvm-svn: 228984
-
Hans Wennborg authored
```--------------------------------------------------------------------- r228979 | majnemer | 2015-02-12 15:26:26 -0800 (Thu, 12 Feb 2015) | 8 lines X86: Don't crash if we can't decode the pshufb mask Constant pool entries are uniqued by their contents regardless of their type. This means that a pshufb can have a shuffle mask which isn't a simple array of bytes. The code path which attempts to decode the mask didn't check for failure, causing PR22559. ``` --------------------------------------------------------------------- llvm-svn: 228983
-
Hans Wennborg authored
```--------------------------------------------------------------------- r228957 | bsteinbr | 2015-02-12 13:04:22 -0800 (Thu, 12 Feb 2015) | 14 lines Fix a crash in the assumption cache when inlining indirect function calls Summary: Instances of the AssumptionCache are per function, so we can't re-use the same AssumptionCache instance when recursing in the CallAnalyzer to analyze a different function. Instead we have to pass the AssumptionCacheTracker to the CallAnalyzer so it can get the right AssumptionCache on demand. Reviewers: hfinkel Subscribers: llvm-commits, hans Differential Revision: http://reviews.llvm.org/D7533 ``` --------------------------------------------------------------------- llvm-svn: 228965
-
Hans Wennborg authored
```--------------------------------------------------------------------- r228842 | jvoung | 2015-02-11 08:12:50 -0800 (Wed, 11 Feb 2015) | 17 lines Gold-plugin: Broaden scope of get/release_input_file to scope of Module. Summary: Move calls to get_input_file and release_input_file out of getModuleForFile(). Otherwise release_input_file may end up unmapping a view of the file while the view is still being used by the Module (on 32-bit hosts). Fix for PR22482. Test Plan: Add test using --no-map-whole-files. Reviewers: rafael, nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7539 ``` --------------------------------------------------------------------- llvm-svn: 228942
-
Hans Wennborg authored
```--------------------------------------------------------------------- r228899 | chandlerc | 2015-02-11 18:30:56 -0800 (Wed, 11 Feb 2015) | 28 lines [slp] Fix a nasty bug in the SLP vectorizer that Joerg pointed out. Apparently some code finally started to tickle this after my canonicalization changes to instcombine. The bug stems from trying to form a vector type out of scalars that aren't compatible at all. In this example, from x86_mmx values. The code in the vectorizer that checks for reasonable types whas checking for aggregates or vectors, but there are lots of other types that should just never reach the vectorizer. Debugging this was made more confusing by the lie in an assert in VectorType::get() -- it isn't that the types are *primitive*. The types must be integer, pointer, or floating point types. No other types are allowed. I've improved the assert and added a helper to the vectorizer to handle the element type validity checks. It now re-uses the VectorType static function and then further excludes weird target-specific types that we probably shouldn't be touching here (x86_fp80 and ppc_fp128). Neither of these are really reachable anyways (neither 80-bit nor 128-bit things will get vectorized) but it seems better to just eagerly exclude such nonesense. I've added a test case, but while it definitely covers two of the paths through this code there may be more paths that would benefit from test coverage. I'm not familiar enough with the SLP vectorizer to synthesize test cases for all of these, but was able to update the code itself by inspection. ``` --------------------------------------------------------------------- llvm-svn: 228940
-