and though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here

  1. 25 Feb, 2015 1 commit
    • Hans Wennborg's avatar
      Revert 224782: "Finish removing DestroySource." · 27bbb819
      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
      27bbb819
  2. 24 Feb, 2015 5 commits
  3. 23 Feb, 2015 3 commits
  4. 20 Feb, 2015 3 commits
  5. 19 Feb, 2015 3 commits
  6. 18 Feb, 2015 5 commits
    • Hans Wennborg's avatar
      Merging r229731: · 82a2d4d5
      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
      82a2d4d5
    • Hans Wennborg's avatar
      Merging r229719: · dd419802
      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
      dd419802
    • Hans Wennborg's avatar
      Release notes: remove in-progress warnings · 82b7742e
      Hans Wennborg authored
      llvm-svn: 229713
      82b7742e
    • Hans Wennborg's avatar
      Remove another in-progress warning · 4213f74b
      Hans Wennborg authored
      llvm-svn: 229712
      4213f74b
    • Hans Wennborg's avatar
      Remove warnings about the release notes being for the 'next' release · 42f76424
      Hans Wennborg authored
      llvm-svn: 229711
      42f76424
  7. 17 Feb, 2015 9 commits
    • Hans Wennborg's avatar
      Merging r229352: · da2fc4c9
      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
      da2fc4c9
    • Hans Wennborg's avatar
      a2c28378
    • Hans Wennborg's avatar
      Merging r229529: · 53708497
      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
      53708497
    • Hans Wennborg's avatar
      Merging r229495: · 378df91b
      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
      378df91b
    • Hans Wennborg's avatar
      Merging r226808: · 8add0ee9
      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
      8add0ee9
    • Hans Wennborg's avatar
      Merging r226791: · 5ba91fb1
      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
      5ba91fb1
    • Hans Wennborg's avatar
      Merging r229343 and r229351: · f6eb7ae0
      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
      f6eb7ae0
    • Hans Wennborg's avatar
      Merging r229408: · 524b6abc
      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
      524b6abc
    • Hans Wennborg's avatar
      Merging r229421: · 943a8989
      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
      943a8989
  8. 16 Feb, 2015 1 commit
  9. 14 Feb, 2015 1 commit
  10. 13 Feb, 2015 2 commits
    • Tobias Grosser's avatar
      Revert "Add support for pointer types in expressions" · 768f836b
      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
      768f836b
    • Hans Wennborg's avatar
      Merging r229029, minus the test which didn't work on the branch: · 602ad0e6
      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
      602ad0e6
  11. 12 Feb, 2015 7 commits
    • Hans Wennborg's avatar
      Merging r228969: · 022a4c41
      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
      022a4c41
    • Hans Wennborg's avatar
      Merging r226616: · aae610a1
      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
      aae610a1
    • Hans Wennborg's avatar
      Merging r226588: · e27e03b9
      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
      e27e03b9
    • Hans Wennborg's avatar
      Merging r228979: · 6a4ed8e3
      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
      6a4ed8e3
    • Hans Wennborg's avatar
      Merging r228957: · 2f356a13
      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
      2f356a13
    • Hans Wennborg's avatar
      Merging r228842: · 1a8cc869
      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
      1a8cc869
    • Hans Wennborg's avatar
      Merging r228899: · e022d920
      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
      e022d920