Skip to content
  1. Jun 17, 2020
    • Nick Desaulniers's avatar
      BreakCriticalEdges for callbr indirect dests · 88c965ba
      Nick Desaulniers authored
      Summary:
      llvm::SplitEdge was failing an assertion that the BasicBlock only had
      one successor (for BasicBlocks terminated by CallBrInst, we typically
      have multiple successors).  It was surprising that the earlier call to
      SplitCriticalEdge did not handle the critical edge (there was an early
      return).  Removing that triggered another assertion relating to creating
      a BlockAddress for a BasicBlock that did not (yet) have a parent, which
      is a simple order of operations issue in llvm::SplitCriticalEdge (a
      freshly constructed BasicBlock must be inserted into a Function's basic
      block list to have a parent).
      
      Thanks to @nathanchance for the report.
      Fixes: https://github.com/ClangBuiltLinux/linux/issues/1018
      
      Reviewers: craig.topper, jyknight, void, fhahn, efriedma
      
      Reviewed By: efriedma
      
      Subscribers: eli.friedman, rnk, efriedma, fhahn, hiraditya, llvm-commits, nathanchance, srhines
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D81607
      88c965ba
    • Hans Wennborg's avatar
      [IR] Don't copy profile metadata in createCallMatchingInvoke() · 16ad6eeb
      Hans Wennborg authored
      The invoke instruction can have profile metadata with branch_weights,
      which does not make sense for a call instruction and will be
      rejected by the verifier.
      
      Differential revision: https://reviews.llvm.org/D81996
      16ad6eeb
  2. Jun 16, 2020
  3. Jun 14, 2020
    • Whitney Tsang's avatar
      [LoopUnroll] Allow loops with multiple exiting blocks where loop latch · 5225cd43
      Whitney Tsang authored
      is not necessary one of them.
      
      Summary: Currently LoopUnrollPass already allow loops with multiple
      exiting blocks, but it is only allowed when the loop latch is one of the
      exiting blocks.
      When the loop latch is not an exiting block, then only single exiting
      block is supported.
      When possible, the single loop latch or the single exiting block
      terminator is optimized to an unconditional branch in the unrolled loop.
      
      This patch allows loops with multiple exiting blocks even if the loop
      latch is not one of them. However, the optimization of exiting block
      terminator to unconditional branch is not done when there exists more
      than one exiting block.
      Reviewer: dmgreen, Meinersbur, etiotto, fhahn, efriedma, bmahjour
      Reviewed By: efriedma
      Subscribers: hiraditya, zzheng, llvm-commits
      Tag: LLVM
      Differential Revision: https://reviews.llvm.org/D81053
      5225cd43
  4. Jun 12, 2020
    • Florian Hahn's avatar
      [BreakCritEdges] Add option to opt-out of perserving loop-simplify. · 4495a6b1
      Florian Hahn authored
      This patch adds a new option to CriticalEdgeSplittingOptions to control
      whether loop-simplify form must be preserved. It is them used by GVN to
      indicate that loop-simplify form does not have to be preserved.
      
      This fixes a crash exposed by 189efe29.
      
      If the critical edge we are splitting goes from a block inside a loop to
      a block outside the loop, splitting the edge will create a new exit
      block. As a result, the new block will branch to the original exit
      block, which will add a non-loop predecessor, breaking loop-simplify
      form. To preserve loop-simplify form, the predecessor blocks of the
      original exit are split, but that does not work for blocks with
      indirectbr terminators. If preserving loop-simplify form is requested,
      bail out , before making any changes.
      
      Reviewers: reames, hfinkel, davide, efriedma
      
      Reviewed By: efriedma
      
      Differential Revision: https://reviews.llvm.org/D81582
      4495a6b1
    • Alina Sbirlea's avatar
      Verify MemorySSA after all updates. · 519b019a
      Alina Sbirlea authored
      Verify after completing all updates.
      Resolves PR46275.
      519b019a
  5. Jun 11, 2020
  6. Jun 10, 2020
  7. Jun 08, 2020
  8. Jun 07, 2020
  9. Jun 06, 2020
  10. Jun 05, 2020
  11. Jun 04, 2020
  12. Jun 01, 2020
    • Sanjay Patel's avatar
      [InstNamer] use 'i' for Instructions, not 'tmp' · dd54432a
      Sanjay Patel authored
      As discussed in https://bugs.llvm.org/show_bug.cgi?id=45951 and
      D80584, the name 'tmp' is almost always a bad choice, but we have
      a legacy of regression tests with that name because it was baked
      into utils/update_test_checks.py.
      
      This change makes -instnamer more consistent (already using "arg"
      and "bb", the common LLVM shorthand). And it avoids the conflict
      in telling users of the FileCheck script to run "-instnamer" to
      create a better regression test and having that cause a warn/fail
      in update_test_checks.py.
      dd54432a
  13. May 30, 2020
  14. May 29, 2020
  15. May 28, 2020
  16. May 27, 2020
    • Rithik Sharma's avatar
      [CodeMoverUtils] Use dominator tree level to decide the direction of · eadf2959
      Rithik Sharma authored
      code motion
      
      Summary: Currently isSafeToMoveBefore uses DFS numbering for determining
      the relative position of instruction and insert point which is not
      always correct. This PR proposes the use of Dominator Tree depth for the
      same. If a node is at a higher level than the insert point then it is
      safe to say that we want to move in the forward direction.
      Authored By: RithikSharma
      Reviewer: Whitney, nikic, bmahjour, etiotto, fhahn
      Reviewed By: Whitney
      Subscribers: fhahn, hiraditya, llvm-commits
      Tag: LLVM
      Differential Revision: https://reviews.llvm.org/D80084
      eadf2959
    • David Green's avatar
      [UnJ] Update LI for inner nested loops · 70d4a202
      David Green authored
      This makes sure to correctly register the loop info of the children
      of unroll and jammed loops. It re-uses some code from the unroller for
      registering subloops.
      
      Differential Revision: https://reviews.llvm.org/D80619
      70d4a202
    • Djordje Todorovic's avatar
      [NFC][Debugify] Format the CheckModuleDebugify output · 65030821
      Djordje Todorovic authored
      This fixes the output of the check-debugify option.
      Without the patch an example of running the option:
      
      $ opt -check-debugify test.ll -S -o testDebugify.ll
      CheckModuleDebugifySkipping module without debugify metadata
      
      After the patch:
      
      $ opt -check-debugify test.ll -S -o testDebugify.ll
      CheckModuleDebugify: Skipping module without debugify metadata
      
      Differential Revision: https://reviews.llvm.org/D80553
      65030821
  17. May 26, 2020
    • Florian Hahn's avatar
      [LoopUnroll] Simplify latch/header block handling (NFC). · 5cf90d6c
      Florian Hahn authored
      I think the current code dealing with connecting the unrolled iterations
      is a bit more complicated than necessary currently. To connect the
      unrolled iterations, we have to update the unrolled latch blocks to
      branch to the header of the next unrolled iteration.
      
      We need to do this regardless whether the latch is exiting or not.
      
      Additionally, we try to turn the conditional branch in the exiting block
      to an unconditional one. This is an optimization only; alternatively we
      could leave the conditional branches in place and rely on other passes
      to simplify the conditions.
      
      Logically, this is a separate step from connecting the latches to the
      headers, but it is convenient to fold them into the same loop, if the
      latch is also exiting. For headers (or other non-latch exiting blocks,
      this is done separately).
      
      Hopefully the patch with additional comments makes things a bit clearer.
      
      Reviewers: efriedma, dmgreen, hfinkel, Whitney
      
      Reviewed By: efriedma
      
      Differential Revision: https://reviews.llvm.org/D80544
      5cf90d6c
    • Serge Pavlov's avatar
      [FPEnv] Intrinsic llvm.roundeven · 4d20e31f
      Serge Pavlov authored
      This intrinsic implements IEEE-754 operation roundToIntegralTiesToEven,
      and performs rounding to the nearest integer value, rounding halfway
      cases to even. The intrinsic represents the missed case of IEEE-754
      rounding operations and now llvm provides full support of the rounding
      operations defined by the standard.
      
      Differential Revision: https://reviews.llvm.org/D75670
      4d20e31f
  18. May 25, 2020
Loading