Skip to content
  1. Feb 06, 2019
  2. Jan 19, 2019
    • Chandler Carruth's avatar
      Update the file headers across all of the LLVM projects in the monorepo · 2946cd70
      Chandler Carruth authored
      to reflect the new license.
      
      We understand that people may be surprised that we're moving the header
      entirely to discuss the new license. We checked this carefully with the
      Foundation's lawyer and we believe this is the correct approach.
      
      Essentially, all code in the project is now made available by the LLVM
      project under our new license, so you will see that the license headers
      include that license only. Some of our contributors have contributed
      code under our old license, and accordingly, we have retained a copy of
      our old license notice in the top-level files in each project and
      repository.
      
      llvm-svn: 351636
      2946cd70
  3. Jan 14, 2019
    • Max Kazantsev's avatar
      [BasicBlockUtils] Generalize DeleteDeadBlock to deal with multiple dead blocks · 1f73310e
      Max Kazantsev authored
      Utility function `DeleteDeadBlock` expects that all predecessors of a block being
      deleted are already deleted, with the exception of single-block loop. It makes it
      hard to use for deletion of a set of blocks that may contain cyclic dependencies.
      The is no correct order of invocations of this function that does not produce
      dangling pointers on already deleted blocks.
      
      This patch introduces a generalized version of this function `DeleteDeadBlocks`
      that allows us to remove multiple blocks at once, even if there are cycles among
      them. The only requirement is that no block being deleted should have a predecessor
      that is not being deleted. 
      
      The logic of `DeleteDeadBlocks` is following:
        for each block
          create relevant DT updates;
          remove all instructions (replace with undef if needed);
          replace terminator with unreacheable;
        apply DT updates;
        for each block
          delete block;
      
      Therefore, `DeleteDeadBlock` becomes a particular case of
      the general algorithm called for a single block.
      
      Differential Revision: https://reviews.llvm.org/D56120
      Reviewed By: skatkov
      
      llvm-svn: 351045
      1f73310e
  4. Oct 15, 2018
  5. Aug 26, 2018
    • Chandler Carruth's avatar
      [IR] Sink `isExceptional` predicate to `Instruction`, rename it to · 698fbe7b
      Chandler Carruth authored
      `isExceptionalTermiantor` and implement it for opcodes as well following
      the common pattern in `Instruction`.
      
      Part of removing `TerminatorInst` from the `Instruction` type hierarchy
      to make it easier to share logic and interfaces between instructions
      that are both terminators and not terminators.
      
      llvm-svn: 340699
      698fbe7b
    • Chandler Carruth's avatar
      [IR] Begin removal of TerminatorInst by removing successor manipulation. · 96fc1de7
      Chandler Carruth authored
      The core get and set routines move to the `Instruction` class. These
      routines are only valid to call on instructions which are terminators.
      
      The iterator and *generic* range based access move to `CFG.h` where all
      the other generic successor and predecessor access lives. While moving
      the iterator here, simplify it using the iterator utilities LLVM
      provides and updates coding style as much as reasonable. The APIs remain
      pointer-heavy when they could better use references, and retain the odd
      behavior of `operator*` and `operator->` that is common in LLVM
      iterators. Adjusting this API, if desired, should be a follow-up step.
      
      Non-generic range iteration is added for the two instructions where
      there is an especially easy mechanism and where there was code
      attempting to use the range accessor from a specific subclass:
      `indirectbr` and `br`. In both cases, the successors are contiguous
      operands and can be easily iterated via the operand list.
      
      This is the first major patch in removing the `TerminatorInst` type from
      the IR's instruction type hierarchy. This change was discussed in an RFC
      here and was pretty clearly positive:
      http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html
      
      There will be a series of much more mechanical changes following this
      one to complete this move.
      
      Differential Revision: https://reviews.llvm.org/D47467
      
      llvm-svn: 340698
      96fc1de7
  6. Aug 22, 2018
  7. Aug 04, 2018
    • Chijun Sima's avatar
      [TailCallElim] Preserve DT and PDT · 8b5de48d
      Chijun Sima authored
      Summary:
      Previously, in the NewPM pipeline, TailCallElim recalculates the DomTree when it modifies any instruction in the Function.
      For example,
      ```
      CallInst *CI = dyn_cast<CallInst>(&I);
      ...
      CI->setTailCall();
      Modified = true;
      ...
      if (!Modified || ...)
        return PreservedAnalyses::all();
      ```
      After applying this patch, the DomTree only recalculates if needed (plus an extra insertEdge() + an extra deleteEdge() call).
      
      When optimizing SQLite with `-passes="default<O3>"` pipeline of the newPM, the number of DomTree recalculation decreases by 6.2%, the number of nodes visited by DFS decreases by 2.9%. The time used by DomTree will decrease approximately 1%~2.5% after applying the patch.
       
      Statistics:
      ```
      Before the patch:
       23010 dom-tree-stats               - Number of DomTree recalculations
      489264 dom-tree-stats               - Number of nodes visited by DFS -- DomTree
      After the patch:
       21581 dom-tree-stats               - Number of DomTree recalculations
      475088 dom-tree-stats               - Number of nodes visited by DFS -- DomTree
      ```
      
      Reviewers: kuhar, dmgreen, brzycki, grosser, davide
      
      Reviewed By: kuhar, brzycki
      
      Subscribers: llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D49982
      
      llvm-svn: 338954
      8b5de48d
  8. Aug 03, 2018
  9. Jun 21, 2018
    • Alina Sbirlea's avatar
      Generalize MergeBlockIntoPredecessor. Replace uses of MergeBasicBlockIntoOnlyPred. · dfd14ade
      Alina Sbirlea authored
      Summary:
      Two utils methods have essentially the same functionality. This is an attempt to merge them into one.
      1. lib/Transforms/Utils/Local.cpp : MergeBasicBlockIntoOnlyPred
      2. lib/Transforms/Utils/BasicBlockUtils.cpp : MergeBlockIntoPredecessor
      
      Prior to the patch:
      1. MergeBasicBlockIntoOnlyPred
      Updates either DomTree or DeferredDominance
      Moves all instructions from Pred to BB, deletes Pred
      Asserts BB has single predecessor
      If address was taken, replace the block address with constant 1 (?)
      
      2. MergeBlockIntoPredecessor
      Updates DomTree, LoopInfo and MemoryDependenceResults
      Moves all instruction from BB to Pred, deletes BB
      Returns if doesn't have a single predecessor
      Returns if BB's address was taken
      
      After the patch:
      Method 2. MergeBlockIntoPredecessor is attempting to become the new default:
      Updates DomTree or DeferredDominance, and LoopInfo and MemoryDependenceResults
      Moves all instruction from BB to Pred, deletes BB
      Returns if doesn't have a single predecessor
      Returns if BB's address was taken
      
      Uses of MergeBasicBlockIntoOnlyPred that need to be replaced:
      
      1. lib/Transforms/Scalar/LoopSimplifyCFG.cpp
      Updated in this patch. No challenges.
      
      2. lib/CodeGen/CodeGenPrepare.cpp
      Updated in this patch.
        i. eliminateFallThrough is straightforward, but I added using a temporary array to avoid the iterator invalidation.
        ii. eliminateMostlyEmptyBlock(s) methods also now use a temporary array for blocks
      Some interesting aspects:
        - Since Pred is not deleted (BB is), the entry block does not need updating.
        - The entry block was being updated with the deleted block in eliminateMostlyEmptyBlock. Added assert to make obvious that BB=SinglePred.
        - isMergingEmptyBlockProfitable assumes BB is the one to be deleted.
        - eliminateMostlyEmptyBlock(BB) does not delete BB on one path, it deletes its unique predecessor instead.
        - adding some test owner as subscribers for the interesting tests modified:
          test/CodeGen/X86/avx-cmp.ll
          test/CodeGen/AMDGPU/nested-loop-conditions.ll
          test/CodeGen/AMDGPU/si-annotate-cf.ll
          test/CodeGen/X86/hoist-spill.ll
          test/CodeGen/X86/2006-11-17-IllegalMove.ll
      
      3. lib/Transforms/Scalar/JumpThreading.cpp
      Not covered in this patch. It is the only use case using the DeferredDominance.
      I would defer to Brian Rzycki to make this replacement.
      
      Reviewers: chandlerc, spatel, davide, brzycki, bkramer, javed.absar
      
      Subscribers: qcolombet, sanjoy, nemanjai, nhaehnle, jlebar, tpr, kbarton, RKSimon, wmi, arsenm, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D48202
      
      llvm-svn: 335183
      dfd14ade
  10. Jun 19, 2018
  11. Jun 04, 2018
    • David Blaikie's avatar
      Move Analysis/Utils/Local.h back to Transforms · 31b98d2e
      David Blaikie authored
      Review feedback from r328165. Split out just the one function from the
      file that's used by Analysis. (As chandlerc pointed out, the original
      change only moved the header and not the implementation anyway - which
      was fine for the one function that was used (since it's a
      template/inlined in the header) but not in general)
      
      llvm-svn: 333954
      31b98d2e
  12. May 09, 2018
    • Davide Italiano's avatar
      [SimplifyCFG] Fix a crash when folding PHIs. · 48283ba3
      Davide Italiano authored
      We enter MergeBlockIntoPredecessor with a block looking like this:
      
      for.inc.us-lcssa:                                 ; preds = %cond.end
        %k.1.lcssa.ph = phi i32 [ %conv15, %cond.end ]
        %t.3.lcssa.ph = phi i32 [ %k.1.lcssa.ph, %cond.end ]
        br label %for.inc, !dbg !66
      
      [note the first arg of the PHI being a PHI].
      FoldSingleEntryPHINodes gets rid of both PHIs (calling, eraseFromParent).
      But right before we call the function, we push into IncomingValues the
      only argument of the PHIs, and shortly after we try to iterate over
      something which has been invalidated before :(
      
      The fix its not trying to remove PHIs which have an incoming value
      coming from the same BB we're looking at.
      
      Fixes PR37300 and rdar://problem/39910460
      
      Differential Revision:  https://reviews.llvm.org/D46568
      
      llvm-svn: 331824
      48283ba3
  13. Mar 21, 2018
    • David Blaikie's avatar
      Fix a couple of layering violations in Transforms · 2be39228
      David Blaikie authored
      Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering.
      
      Transforms depends on Transforms/Utils, not the other way around. So
      remove the header and the "createStripGCRelocatesPass" function
      declaration (& definition) that is unused and motivated this dependency.
      
      Move Transforms/Utils/Local.h into Analysis because it's used by
      Analysis/MemoryBuiltins.cpp.
      
      llvm-svn: 328165
      2be39228
  14. Jan 31, 2018
  15. Jan 12, 2018
    • Brian M. Rzycki's avatar
      [JumpThreading] Preservation of DT and LVI across the pass · 9b7ae232
      Brian M. Rzycki authored
      Summary:
      See D37528 for a previous (non-deferred) version of this
      patch and its description.
      
      Preserves dominance in a deferred manner using a new class
      DeferredDominance. This reduces the performance impact of
      updating the DominatorTree at every edge insertion and
      deletion. A user may call DDT->flush() within JumpThreading
      for an up-to-date DT. This patch currently has one flush()
      at the end of runImpl() to ensure DT is preserved across
      the pass.
      
      LVI is also preserved to help subsequent passes such as
      CorrelatedValuePropagation. LVI is simpler to maintain and
      is done immediately (not deferred). The code to perform the
      preversation was minimally altered and simply marked as
      preserved for the PassManager to be informed.
      
      This extends the analysis available to JumpThreading for
      future enhancements such as threading across loop headers.
      
      Reviewers: dberlin, kuhar, sebpop
      
      Reviewed By: kuhar, sebpop
      
      Subscribers: mgorny, dmgreen, kuba, rnk, rsmith, hiraditya, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D40146
      
      llvm-svn: 322401
      9b7ae232
  16. Jan 05, 2018
  17. Jan 04, 2018
    • Brian M. Rzycki's avatar
      [JumpThreading] Preservation of DT and LVI across the pass · cdad6c0b
      Brian M. Rzycki authored
      Summary:
      See D37528 for a previous (non-deferred) version of this
      patch and its description.
      
      Preserves dominance in a deferred manner using a new class
      DeferredDominance. This reduces the performance impact of
      updating the DominatorTree at every edge insertion and
      deletion. A user may call DDT->flush() within JumpThreading
      for an up-to-date DT. This patch currently has one flush()
      at the end of runImpl() to ensure DT is preserved across
      the pass.
      
      LVI is also preserved to help subsequent passes such as
      CorrelatedValuePropagation. LVI is simpler to maintain and
      is done immediately (not deferred). The code to perfom the
      preversation was minimally altered and was simply marked
      as preserved for the PassManager to be informed.
      
      This extends the analysis available to JumpThreading for
      future enhancements. One example is loop boundary threading.
      
      Reviewers: dberlin, kuhar, sebpop
      
      Reviewed By: kuhar, sebpop
      
      Subscribers: hiraditya, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D40146
      
      llvm-svn: 321825
      cdad6c0b
    • Anna Thomas's avatar
      Add assertion on DT availability during LI update in UpdateAnalysisInformation · 9fca5837
      Anna Thomas authored
      This came up during discussions in llvm-commits for
      rL321653: Check for unreachable preds before updating LI in
      UpdateAnalysisInformation
      
      The assert provides hints to passes to require both DT and LI if we plan on
      updating LI through this function.
      
      Tests run: make check
      
      llvm-svn: 321805
      9fca5837
  18. Jan 02, 2018
    • Anna Thomas's avatar
      [BasicBlockUtils] Check for unreachable preds before updating LI in UpdateAnalysisInformation · bdb94309
      Anna Thomas authored
      Summary:
      We are incorrectly updating the LI when loop-simplify generates
      dedicated exit blocks for a loop. The issue is that there's an implicit
      assumption that the Preds passed into UpdateAnalysisInformation are
      reachable. However, this is not true and breaks LI by incorrectly
      updating the header of a loop.
      
      One such case is when we generate dedicated exits when the exit block is
      a landing pad (through SplitLandingPadPredecessors). There maybe other
      cases as well, since we do not guarantee that Preds passed in are
      reachable basic blocks.
      
      The added test case shows how loop-simplify breaks LI for the outer loop (and DT in turn)
      after we try to generate the LoopSimplifyForm.
      
      Reviewers: davide, chandlerc, sanjoy
      
      Reviewed By: davide
      
      Subscribers: llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D41519
      
      llvm-svn: 321653
      bdb94309
  19. Dec 30, 2017
  20. Dec 13, 2017
    • Brian M. Rzycki's avatar
    • Brian M. Rzycki's avatar
      [JumpThreading] Preservation of DT and LVI across the pass · d989af98
      Brian M. Rzycki authored
      Summary:
      See D37528 for a previous (non-deferred) version of this
      patch and its description.
      
      Preserves dominance in a deferred manner using a new class
      DeferredDominance. This reduces the performance impact of
      updating the DominatorTree at every edge insertion and
      deletion. A user may call DDT->flush() within JumpThreading
      for an up-to-date DT. This patch currently has one flush()
      at the end of runImpl() to ensure DT is preserved across
      the pass.
      
      LVI is also preserved to help subsequent passes such as
      CorrelatedValuePropagation. LVI is simpler to maintain and
      is done immediately (not deferred). The code to perfom the
      preversation was minimally altered and was simply marked
      as preserved for the PassManager to be informed.
      
      This extends the analysis available to JumpThreading for
      future enhancements. One example is loop boundary threading.
      
      Reviewers: dberlin, kuhar, sebpop
      
      Reviewed By: kuhar, sebpop
      
      Subscribers: hiraditya, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D40146
      
      llvm-svn: 320612
      d989af98
  21. Nov 01, 2017
  22. Oct 27, 2017
  23. May 01, 2017
  24. Apr 26, 2017
    • Sanjoy Das's avatar
      Reverts commit r301424, r301425 and r301426 · 2cbeb00f
      Sanjoy Das authored
      Commits were:
      
      "Use WeakVH instead of WeakTrackingVH in AliasSetTracker's UnkownInsts"
      "Add a new WeakVH value handle; NFC"
      "Rename WeakVH to WeakTrackingVH; NFC"
      
      The changes assumed pointers are 8 byte aligned on all architectures.
      
      llvm-svn: 301429
      2cbeb00f
    • Sanjoy Das's avatar
      Rename WeakVH to WeakTrackingVH; NFC · 01de5577
      Sanjoy Das authored
      Summary:
      I plan to use WeakVH to mean "nulls itself out on deletion, but does
      not track RAUW" in a subsequent commit.
      
      Reviewers: dblaikie, davide
      
      Reviewed By: davide
      
      Subscribers: arsenm, mehdi_amini, mcrosier, mzolotukhin, jfb, llvm-commits, nhaehnle
      
      Differential Revision: https://reviews.llvm.org/D32266
      
      llvm-svn: 301424
      01de5577
  25. Mar 06, 2017
    • Michael Kruse's avatar
      [BasicBlockUtils] Check for nullptr before updating LoopInfo. · 811de8a6
      Michael Kruse authored
      LoopInfo::getLoopFor returns nullptr if a BB is not in a loop and only
      then can the loop be updated to contain the newly created BBs. Add the
      missing nullptr check to SplitBlockAndInsertIfThen.
      
      Within LLVM, the only user of this function that also passes a LoopInfo
      to be updated is InnerLoopVectorizer::predicateInstructions().
      As the method's name implies, the BB operataten on will always be within
      a loop, but out-of-tree users may also use it differently (here: Polly).
      
      All other uses of LoopInfo::getLoopFor in the file properly check its
      return value for nullptr.
      
      llvm-svn: 297016
      811de8a6
  26. Feb 14, 2017
    • Taewook Oh's avatar
      [BasicBlockUtils] Use getFirstNonPHIOrDbg to set debugloc for instructions... · 2e945ebb
      Taewook Oh authored
      [BasicBlockUtils] Use getFirstNonPHIOrDbg to set debugloc for instructions created in SplitBlockPredecessors
      
      Summary:
      When setting debugloc for instructions created in SplitBlockPredecessors, current implementation copies debugloc from the first-non-phi instruction of the original basic block. However, if the first-non-phi instruction is a call for @llvm.dbg.value, the debugloc of the instruction may point the location outside of the block itself. For the example code of
      
      ```
        1 typedef struct _node_t {
        2   struct _node_t *next;
        3 } node_t;
        4
        5 extern node_t *root;
        6
        7 int foo() {
        8   node_t *node, *tmp;
        9   int ret = 0;
       10
       11   node = tmp = root->next;
       12   while (node != root) {
       13     while (node) {
       14       tmp = node;
       15       node = node->next;
       16       ret++;
       17     }
       18   }
       19
       20   return ret;
       21 }
      ```
      
      , below is the basicblock corresponding to line 12 after Reassociate expressions pass:
      
      ```
      while.cond:                                       ; preds = %while.cond2, %entry
        %node.0 = phi %struct._node_t* [ %1, %entry ], [ null, %while.cond2 ]
        %ret.0 = phi i32 [ 0, %entry ], [ %ret.1, %while.cond2 ]
        tail call void @llvm.dbg.value(metadata i32 %ret.0, i64 0, metadata !19, metadata !20), !dbg !21
        tail call void @llvm.dbg.value(metadata %struct._node_t* %node.0, i64 0, metadata !11, metadata !20), !dbg !31
        %cmp = icmp eq %struct._node_t* %node.0, %0, !dbg !33
        br i1 %cmp, label %while.end5, label %while.cond2, !dbg !35
      ```
      
      As you can see, the first-non-phi instruction is a call for @llvm.dbg.value, and the debugloc is
      
      ```
      !21 = !DILocation(line: 9, column: 7, scope: !6)
      ```
      
      , which is a definition of 'ret' variable and outside of the scope of the basicblock itself. However, current implementation picks up this debugloc for the instructions created in SplitBlockPredecessors. This patch addresses this problem by picking up debugloc from the first-non-phi-non-dbg instruction.
      
      Reviewers: dblaikie, samsonov, eugenis
      
      Reviewed By: eugenis
      
      Subscribers: llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D29867
      
      llvm-svn: 295106
      2e945ebb
  27. Jun 26, 2016
  28. Apr 23, 2016
  29. Mar 15, 2016
    • Adam Nemet's avatar
      [LV] Preserve LoopInfo when store predication is used · fdb20595
      Adam Nemet authored
      This was a latent bug that got exposed by the change to add LoopSimplify
      as a dependence to LoopLoadElimination.  Since LoopInfo was corrupted
      after LV, LoopSimplify mis-compiled nbench in the test-suite (more
      details in the PR).
      
      The problem was that when we create the blocks for predicated stores we
      didn't add those to any loops.
      
      The original testcase for store predication provides coverage for this
      assuming we verify LI on the way out of LV.
      
      Fixes PR26952.
      
      llvm-svn: 263565
      fdb20595
  30. Mar 10, 2016
    • Chandler Carruth's avatar
      [PM] Port memdep to the new pass manager. · 61440d22
      Chandler Carruth authored
      This is a fairly straightforward port to the new pass manager with one
      exception. It removes a very questionable use of releaseMemory() in
      the old pass to invalidate its caches between runs on a function.
      I don't think this is really guaranteed to be safe. I've just used the
      more direct port to the new PM to address this by nuking the results
      object each time the pass runs. While this could cause some minor malloc
      traffic increase, I don't expect the compile time performance hit to be
      noticable, and it makes the correctness and other aspects of the pass
      much easier to reason about. In some cases, it may make things faster by
      making the sets and maps smaller with better locality. Indeed, the
      measurements collected by Bruno (thanks!!!) show mostly compile time
      improvements.
      
      There is sadly very limited testing at this point as there are only two
      tests of memdep, and both rely on GVN. I'll be porting GVN next and that
      will exercise this heavily though.
      
      Differential Revision: http://reviews.llvm.org/D17962
      
      llvm-svn: 263082
      61440d22
  31. Jan 06, 2016
    • Chen Li's avatar
      [SplitLandingPadPredecessors] Create a PHINode for the original landingpad only if it has some uses · 78bde830
      Chen Li authored
      Summary: This patch adds a check in SplitLandingPadPredecessors to see if the original landingpad instruction has any uses. If not, we don't need to create a PHINode for it in the joint block since it's gonna be a dead code anyway. The motivation for this patch is that we found a bug that SplitLandingPadPredecessors created a PHINode of token type landingpad, which failed the verifier since PHINode can not be token type. However, the created PHINode will never be used in our code pattern. This patch will workaround this bug, and we might add supports in SplitLandingPadPredecessors to handle token type landingpad with uses in the future.
      
      Reviewers: reames
      
      Subscribers: llvm-commits
      
      Differential Revision: http://reviews.llvm.org/D15835
      
      llvm-svn: 256972
      78bde830
  32. Oct 13, 2015
Loading