Skip to content
  1. May 13, 2020
  2. May 07, 2020
    • Yevgeny Rouban's avatar
      SplitIndirectBrCriticalEdges: Fix Branch Probability update · b921543c
      Yevgeny Rouban authored
      Splitting critical edges for indirect branches
      the SplitIndirectBrCriticalEdges() function may break branch
      probabilities if target basic block happens to have unset
      a probability for any of its successors. That is because in
      such cases the getEdgeProbability(Target) function returns
      probability 1/NumOfSuccessors and it is called after Target
      was split (thus Target has a single successor). As the result
      the correspondent successor of the split block gets
      probability 100% but 1/NumOfSuccessors is expected (or better
      be left unset).
      
      Reviewers: yamauchi
      Differential Revision: https://reviews.llvm.org/D78806
      b921543c
  3. Nov 14, 2019
    • Reid Kleckner's avatar
      Sink all InitializePasses.h includes · 05da2fe5
      Reid Kleckner authored
      This file lists every pass in LLVM, and is included by Pass.h, which is
      very popular. Every time we add, remove, or rename a pass in LLVM, it
      caused lots of recompilation.
      
      I found this fact by looking at this table, which is sorted by the
      number of times a file was changed over the last 100,000 git commits
      multiplied by the number of object files that depend on it in the
      current checkout:
        recompiles    touches affected_files  header
        342380        95      3604    llvm/include/llvm/ADT/STLExtras.h
        314730        234     1345    llvm/include/llvm/InitializePasses.h
        307036        118     2602    llvm/include/llvm/ADT/APInt.h
        213049        59      3611    llvm/include/llvm/Support/MathExtras.h
        170422        47      3626    llvm/include/llvm/Support/Compiler.h
        162225        45      3605    llvm/include/llvm/ADT/Optional.h
        158319        63      2513    llvm/include/llvm/ADT/Triple.h
        140322        39      3598    llvm/include/llvm/ADT/StringRef.h
        137647        59      2333    llvm/include/llvm/Support/Error.h
        131619        73      1803    llvm/include/llvm/Support/FileSystem.h
      
      Before this change, touching InitializePasses.h would cause 1345 files
      to recompile. After this change, touching it only causes 550 compiles in
      an incremental rebuild.
      
      Reviewers: bkramer, asbirlea, bollu, jdoerfert
      
      Differential Revision: https://reviews.llvm.org/D70211
      05da2fe5
  4. Mar 12, 2019
    • Craig Topper's avatar
      [SanitizerCoverage] Avoid splitting critical edges when destination is a basic... · 03e93f51
      Craig Topper authored
      [SanitizerCoverage] Avoid splitting critical edges when destination is a basic block containing unreachable
      
      This patch adds a new option to SplitAllCriticalEdges and uses it to avoid splitting critical edges when the destination basic block ends with unreachable. Otherwise if we split the critical edge, sanitizer coverage will instrument the new block that gets inserted for the split. But since this block itself shouldn't be reachable this is pointless. These basic blocks will stick around and generate assembly, but they don't end in sane control flow and might get placed at the end of the function. This makes it look like one function has code that flows into the next function.
      
      This showed up while compiling the linux kernel with clang. The kernel has a tool called objtool that detected the code that appeared to flow from one function to the next. https://github.com/ClangBuiltLinux/linux/issues/351#issuecomment-461698884
      
      Differential Revision: https://reviews.llvm.org/D57982
      
      llvm-svn: 355947
      03e93f51
  5. Feb 22, 2019
  6. Feb 12, 2019
  7. Feb 08, 2019
    • Craig Topper's avatar
      Implementation of asm-goto support in LLVM · 784929d0
      Craig Topper authored
      This patch accompanies the RFC posted here:
      http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html
      
      This patch adds a new CallBr IR instruction to support asm-goto
      inline assembly like gcc as used by the linux kernel. This
      instruction is both a call instruction and a terminator
      instruction with multiple successors. Only inline assembly
      usage is supported today.
      
      This also adds a new INLINEASM_BR opcode to SelectionDAG and
      MachineIR to represent an INLINEASM block that is also
      considered a terminator instruction.
      
      There will likely be more bug fixes and optimizations to follow
      this, but we felt it had reached a point where we would like to
      switch to an incremental development model.
      
      Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii
      
      Differential Revision: https://reviews.llvm.org/D53765
      
      llvm-svn: 353563
      784929d0
  8. 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
  9. Oct 15, 2018
    • Chandler Carruth's avatar
      [TI removal] Make variables declared as `TerminatorInst` and initialized · edb12a83
      Chandler Carruth authored
      by `getTerminator()` calls instead be declared as `Instruction`.
      
      This is the biggest remaining chunk of the usage of `getTerminator()`
      that insists on the narrow type and so is an easy batch of updates.
      Several files saw more extensive updates where this would cascade to
      requiring API updates within the file to use `Instruction` instead of
      `TerminatorInst`. All of these were trivial in nature (pervasively using
      `Instruction` instead just worked).
      
      llvm-svn: 344502
      edb12a83
    • Chandler Carruth's avatar
      [TI removal] Remove TerminatorInst as an input parameter from all public · b99a2468
      Chandler Carruth authored
      LLVM APIs. There weren't very many.
      
      We still have the instruction visitor, and APIs with TerminatorInst as
      a return type or an output parameter.
      
      llvm-svn: 344494
      b99a2468
  10. Sep 07, 2018
  11. Aug 22, 2018
  12. Mar 28, 2018
  13. Dec 30, 2017
  14. Dec 13, 2017
  15. Dec 12, 2017
    • Hiroshi Yamauchi's avatar
      Split IndirectBr critical edges before PGO gen/use passes. · f3bda1da
      Hiroshi Yamauchi authored
      Summary:
      The PGO gen/use passes currently fail with an assert failure if there's a
      critical edge whose source is an IndirectBr instruction and that edge
      needs to be instrumented.
      
      To avoid this in certain cases, split IndirectBr critical edges in the PGO
      gen/use passes. This works for blocks with single indirectbr predecessors,
      but not for those with multiple indirectbr predecessors (splitting an
      IndirectBr critical edge isn't always possible.)
      
      Reviewers: davidxl, xur
      
      Reviewed By: davidxl
      
      Subscribers: efriedma, llvm-commits, mehdi_amini
      
      Differential Revision: https://reviews.llvm.org/D40699
      
      llvm-svn: 320511
      f3bda1da
  16. Dec 04, 2017
  17. Aug 17, 2017
    • Jakub Kuderski's avatar
      [Dominators] Teach LoopUnswitch to use the incremental API · e35a4491
      Jakub Kuderski authored
      Summary:
      This patch makes LoopUnswitch use new incremental API for updating dominators.
      It also updates SplitCriticalEdge, as it is called in LoopUnswitch.
      
      There doesn't seem to be any noticeable performance difference when bootstrapping clang with this patch.
      
      Reviewers: dberlin, davide, sanjoy, grosser, chandlerc
      
      Reviewed By: davide, grosser
      
      Subscribers: mzolotukhin, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D35528
      
      llvm-svn: 311093
      e35a4491
  18. Jul 22, 2016
  19. Apr 23, 2016
  20. Oct 13, 2015
  21. Aug 04, 2015
  22. Jul 22, 2015
  23. Jun 23, 2015
  24. Jun 19, 2015
  25. Jan 19, 2015
    • Chandler Carruth's avatar
      [PM] Remove the Pass argument from all of the critical edge splitting · 37df2cfb
      Chandler Carruth authored
      APIs and replace it and numerous booleans with an option struct.
      
      The critical edge splitting API has a really large surface of flags and
      so it seems worth burning a small option struct / builder. This struct
      can be constructed with the various preserved analyses and then flags
      can be flipped in a builder style.
      
      The various users are now responsible for directly passing along their
      analysis information. This should be enough for the critical edge
      splitting to work cleanly with the new pass manager as well.
      
      This API is still pretty crufty and could be cleaned up a lot, but I've
      focused on this change just threading an option struct rather than
      a pass through the API.
      
      llvm-svn: 226456
      37df2cfb
    • Chandler Carruth's avatar
      [PM] Relax asserts and always try to reconstruct loop simplify form when · ad34d913
      Chandler Carruth authored
      we can while splitting critical edges.
      
      The only code which called this and didn't require simplified loops to
      be preserved is polly, and the code behaves correctly there anyways.
      Without this change, it becomes really hard to share this code with the
      new pass manager where things like preserving loop simplify form don't
      make any sense.
      
      If anyone discovers this code behaving incorrectly, what it *should* be
      testing for is whether the loops it needs to be in simplified form are
      in fact in that form. It should always be trying to preserve that form
      when it exists.
      
      llvm-svn: 226443
      ad34d913
  26. Jan 18, 2015
    • Chandler Carruth's avatar
      [PM] Pull the analyses used for another utility routine into its API · b5797b65
      Chandler Carruth authored
      rather than relying on the pass object.
      
      This one is a bit annoying, but will pay off. First, supporting this one
      will make the next one much easier, and for utilities like LoopSimplify,
      this is moving them (slowly) closer to not having to pass the pass
      object around throughout their APIs.
      
      llvm-svn: 226396
      b5797b65
    • Chandler Carruth's avatar
      [PM] Now that LoopInfo isn't in the Pass type hierarchy, it is much · 691addc2
      Chandler Carruth authored
      cleaner to derive from the generic base.
      
      Thise removes a ton of boiler plate code and somewhat strange and
      pointless indirections. It also remove a bunch of the previously needed
      friend declarations. To fully remove these, I also lifted the verify
      logic into the generic LoopInfoBase, which seems good anyways -- it is
      generic and useful logic even for the machine side.
      
      llvm-svn: 226385
      691addc2
  27. Jan 17, 2015
  28. Nov 19, 2014
    • Kostya Serebryany's avatar
      Introduce llvm::SplitAllCriticalEdges · e5ea424a
      Kostya Serebryany authored
      Summary:
      move the code from BreakCriticalEdges::runOnFunction()
      into a separate utility function llvm::SplitAllCriticalEdges()
      so that it can be used independently.
      No functionality change intended.
      
      Test Plan: check-llvm
      
      Reviewers: nlewycky
      
      Reviewed By: nlewycky
      
      Subscribers: llvm-commits
      
      Differential Revision: http://reviews.llvm.org/D6313
      
      llvm-svn: 222288
      e5ea424a
  29. Jul 21, 2014
  30. Jul 20, 2014
  31. Apr 25, 2014
  32. Apr 22, 2014
    • Chandler Carruth's avatar
      [Modules] Fix potential ODR violations by sinking the DEBUG_TYPE · 964daaaf
      Chandler Carruth authored
      definition below all of the header #include lines, lib/Transforms/...
      edition.
      
      This one is tricky for two reasons. We again have a couple of passes
      that define something else before the includes as well. I've sunk their
      name macros with the DEBUG_TYPE.
      
      Also, InstCombine contains headers that need DEBUG_TYPE, so now those
      headers #define and #undef DEBUG_TYPE around their code, leaving them
      well formed modular headers. Fixing these headers was a large motivation
      for all of these changes, as "leaky" macros of this form are hard on the
      modules implementation.
      
      llvm-svn: 206844
      964daaaf
  33. Mar 05, 2014
  34. Mar 04, 2014
  35. Jan 29, 2014
    • Chandler Carruth's avatar
      [LPM] Fix PR18643, another scary place where loop transforms failed to · d4be9dc0
      Chandler Carruth authored
      preserve loop simplify of enclosing loops.
      
      The problem here starts with LoopRotation which ends up cloning code out
      of the latch into the new preheader it is buidling. This can create
      a new edge from the preheader into the exit block of the loop which
      breaks LoopSimplify form. The code tries to fix this by splitting the
      critical edge between the latch and the exit block to get a new exit
      block that only the latch dominates. This sadly isn't sufficient.
      
      The exit block may be an exit block for multiple nested loops. When we
      clone an edge from the latch of the inner loop to the new preheader
      being built in the outer loop, we create an exiting edge from the outer
      loop to this exit block. Despite breaking the LoopSimplify form for the
      inner loop, this is fine for the outer loop. However, when we split the
      edge from the inner loop to the exit block, we create a new block which
      is in neither the inner nor outer loop as the new exit block. This is
      a predecessor to the old exit block, and so the split itself takes the
      outer loop out of LoopSimplify form. We need to split every edge
      entering the exit block from inside a loop nested more deeply than the
      exit block in order to preserve all of the loop simplify constraints.
      
      Once we try to do that, a problem with splitting critical edges
      surfaces. Previously, we tried a very brute force to update LoopSimplify
      form by re-computing it for all exit blocks. We don't need to do this,
      and doing this much will sometimes but not always overlap with the
      LoopRotate bug fix. Instead, the code needs to specifically handle the
      cases which can start to violate LoopSimplify -- they aren't that
      common. We need to see if the destination of the split edge was a loop
      exit block in simplified form for the loop of the source of the edge.
      For this to be true, all the predecessors need to be in the exact same
      loop as the source of the edge being split. If the dest block was
      originally in this form, we have to split all of the deges back into
      this loop to recover it. The old mechanism of doing this was
      conservatively correct because at least *one* of the exiting blocks it
      rewrote was the DestBB and so the DestBB's predecessors were fixed. But
      this is a much more targeted way of doing it. Making it targeted is
      important, because ballooning the set of edges touched prevents
      LoopRotate from being able to split edges *it* needs to split to
      preserve loop simplify in a coherent way -- the critical edge splitting
      would sometimes find the other edges in need of splitting but not
      others.
      
      Many, *many* thanks for help from Nick reducing these test cases
      mightily. And helping lots with the analysis here as this one was quite
      tricky to track down.
      
      llvm-svn: 200393
      d4be9dc0
  36. Jan 13, 2014
    • Chandler Carruth's avatar
      [PM] Split DominatorTree into a concrete analysis result object which · 73523021
      Chandler Carruth authored
      can be used by both the new pass manager and the old.
      
      This removes it from any of the virtual mess of the pass interfaces and
      lets it derive cleanly from the DominatorTreeBase<> template. In turn,
      tons of boilerplate interface can be nuked and it turns into a very
      straightforward extension of the base DominatorTree interface.
      
      The old analysis pass is now a simple wrapper. The names and style of
      this split should match the split between CallGraph and
      CallGraphWrapperPass. All of the users of DominatorTree have been
      updated to match using many of the same tricks as with CallGraph. The
      goal is that the common type remains the resulting DominatorTree rather
      than the pass. This will make subsequent work toward the new pass
      manager significantly easier.
      
      Also in numerous places things became cleaner because I switched from
      re-running the pass (!!! mid way through some other passes run!!!) to
      directly recomputing the domtree.
      
      llvm-svn: 199104
      73523021
Loading