Skip to content
  1. Mar 03, 2020
    • Florian Hahn's avatar
      [VPlan] Add getPlan() to VPBlockBase. · 05afa555
      Florian Hahn authored
      This patch adds a getPlan accessor to VPBlockBase, which finds the entry
      block of the plan containing the block and returns the plan set for this
      block.
      
      VPBlockBase contains a VPlan pointer, but it should only be set for
      the entry block of a plan. This allows moving blocks without updating
      the pointer for each moved block and in the future we might introduce a
      parent relationship between plans and blocks, similar to the one in LLVM IR.
      
      Reviewers: rengolin, hsaito, fhahn, Ayal, dorit, gilr
      
      Reviewed By: gilr
      
      Differential Revision: https://reviews.llvm.org/D74445
      05afa555
  2. Mar 02, 2020
  3. Feb 28, 2020
  4. Feb 25, 2020
  5. Feb 22, 2020
  6. Feb 18, 2020
  7. Feb 13, 2020
    • Vedant Kumar's avatar
      [Local] Do not move around dbg.declares during replaceDbgDeclare · 8e77b33b
      Vedant Kumar authored
      replaceDbgDeclare is used to update the descriptions of stack variables
      when they are moved (e.g. by ASan or SafeStack). A side effect of
      replaceDbgDeclare is that it moves dbg.declares around in the
      instruction stream (typically by hoisting them into the entry block).
      This behavior was introduced in llvm/r227544 to fix an assertion failure
      (llvm.org/PR22386), but no longer appears to be necessary.
      
      Hoisting a dbg.declare generally does not create problems. Usually,
      dbg.declare either describes an argument or an alloca in the entry
      block, and backends have special handling to emit locations for these.
      In optimized builds, LowerDbgDeclare places dbg.values in the right
      spots regardless of where the dbg.declare is. And no one uses
      replaceDbgDeclare to handle things like VLAs.
      
      However, there doesn't seem to be a positive case for moving
      dbg.declares around anymore, and this reordering can get in the way of
      understanding other bugs. I propose getting rid of it.
      
      Testing: stage2 RelWithDebInfo sanitized build, check-llvm
      
      rdar://59397340
      
      Differential Revision: https://reviews.llvm.org/D74517
      8e77b33b
  8. Feb 10, 2020
  9. Jan 29, 2020
    • Vedant Kumar's avatar
      [CodeExtractor] Remove stale llvm.assume calls from extracted region · 8359511c
      Vedant Kumar authored
      During extraction, stale llvm.assume handles may be retained in the
      original function. The setup is:
      
      1) CodeExtractor unregisters assumptions in the blocks that are to be
         extracted.
      
      2) Extraction happens. There are now two functions: f1 and f1.extracted.
      
      3) Leftover assumptions in f1 (/not/ removed as they were not in the set of
         blocks to be extracted) now have affected-value llvm.assume handles in
         f1.extracted.
      
      When assumptions for a value used in f1 are looked up, ValueTracking can assert
      as some of the handles are in the wrong function. To fix this, simply erase the
      llvm.assume calls in the extracted function.
      
      Alternatives include flushing the assumption cache in the original function, or
      walking all values used in the original function to prune stale affected-value
      handles. Both seem more expensive.
      
      Testing: check-llvm, LNT run with -mllvm -hot-cold-split enabled
      
      rdar://58460728
      8359511c
  10. Jan 28, 2020
    • Whitney Tsang's avatar
      [CodeMoverUtils] Improve IsControlFlowEquivalent. · 78dc6498
      Whitney Tsang authored
      Summary:
      Currently IsControlFlowEquivalent determine if two blocks are control
      flow equivalent by checking if A dominates B and B post dominates A.
      There exists blocks that are control flow equivalent even if they don't
      satisfy the A dominates B and B post dominates A condition.
      For example,
      
      if (cond)
        A
      if (cond)
        B
      In the PR, we determine if two blocks are control flow equivalent by
      also checking if the two sets of conditions A and B depends on are
      equivalent.
      Reviewer: jdoerfert, Meinersbur, dmgreen, etiotto, bmahjour, fhahn,
      hfinkel, kbarton
      Reviewed By: fhahn
      Subscribers: hiraditya, llvm-commits
      Tag: LLVM
      Differential Revision: https://reviews.llvm.org/D71578
      78dc6498
  11. Jan 23, 2020
    • Fedor Sergeev's avatar
      [LoopRotate] add ability to repeat loop rotation until non-deoptimizing exit is found · 2f6987ba
      Fedor Sergeev authored
      In case of loops with multiple exit where all-but-one exit are deoptimizing
      it might happen that the first rotation will end up with latch having a deoptimizing
      exit. This makes the loop unsuitable for trip-count analysis (say, getLoopEstimatedTripCount)
      as well as for loop transformations that know how to handle multple deoptimizing exits.
      
      It pretty much means that canonical form in multple-deoptimizing-exits case should be
      with non-deoptimizing exit at latch.
      Teach loop-rotation to reach this canonical form by repeating rotation.
      
      -loop-rotate-multi option introduced to control this behavior, currently disabled by default.
      
      Reviewers: skatkov, asbirlea, reames, fhahn
      Reviewed By: skatkov
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D73058
      2f6987ba
  12. Jan 04, 2020
  13. Dec 23, 2019
  14. Dec 22, 2019
  15. Dec 18, 2019
  16. Dec 17, 2019
  17. Dec 10, 2019
    • Yonghong Song's avatar
      [DebugInfo] Support to emit debugInfo for extern variables · d77ae155
      Yonghong Song authored
      Extern variable usage in BPF is different from traditional
      pure user space application. Recent discussion in linux bpf
      mailing list has two use cases where debug info types are
      required to use extern variables:
        - extern types are required to have a suitable interface
          in libbpf (bpf loader) to provide kernel config parameters
          to bpf programs.
          https://lore.kernel.org/bpf/CAEf4BzYCNo5GeVGMhp3fhysQ=_axAf=23PtwaZs-yAyafmXC9g@mail.gmail.com/T/#t
        - extern types are required so kernel bpf verifier can
          verify program which uses external functions more precisely.
          This will make later link with actual external function no
          need to reverify.
          https://lore.kernel.org/bpf/87eez4odqp.fsf@toke.dk/T/#m8d5c3e87ffe7f2764e02d722cb0d8cbc136880ed
      
      This patch added clang support to emit debuginfo for extern variables
      with a TargetInfo hook to enable it. The debuginfo for the
      extern variable is emitted only if that extern variable is
      referenced in the current compilation unit.
      
      Currently, only BPF target enables to generate debug info for
      extern variables. The emission of such debuginfo is disabled for C++
       at this moment since BPF only supports a subset of C language.
      Emission with C++ can be enabled later if an appropriate use case
      is identified.
      
      -fstandalone-debug permits us to see more debuginfo with the cost
      of bloated binary size. This patch did not add emission of extern
      variable debug info with -fstandalone-debug. This can be
      re-evaluated if there is a real need.
      
      Differential Revision: https://reviews.llvm.org/D70696
      d77ae155
  18. Dec 07, 2019
  19. Dec 06, 2019
    • Gil Rapaport's avatar
      [LV] Record GEP widening decisions in recipe (NFCI) · 39ccc099
      Gil Rapaport authored
      InnerLoopVectorizer's code called during VPlan execution still relies on
      original IR's def-use relations to decide which vector code to generate,
      limiting VPlan transformations ability to modify def-use relations and still
      have ILV generate the vector code.
      This commit moves GEP operand queries controlling how GEPs are widened to a
      dedicated recipe and extracts GEP widening code to its own ILV method taking
      those recorded decisions as arguments. This reduces ingredient def-use usage by
      ILV as a step towards full VPlan-based def-use relations.
      
      Differential revision: https://reviews.llvm.org/D69067
      39ccc099
  20. Dec 04, 2019
  21. Nov 27, 2019
  22. Nov 25, 2019
    • OCHyams's avatar
      [DebugInfo@O2][Utils] Undef instead of delete dbg.values in helper func · 2de23c83
      OCHyams authored
      Summary:
      Related bug: https://bugs.llvm.org/show_bug.cgi?id=40648
      
      Static helper function rewriteDebugUsers in Local.cpp deletes dbg.value
      intrinsics when it cannot move or rewrite them, or salvage the deleted
      instruction's value. It should instead undef them in this case.
      
      This patch fixes that and I've added a test which covers the failing test
      case in bz40648. I've updated the unit test Local.ReplaceAllDbgUsesWith
      to check for this behaviour (and fixed a typo in the test which would
      cause the old test to always pass).
      
      Reviewers: aprantl, vsk, djtodoro, probinson
      
      Reviewed By: vsk
      
      Subscribers: hiraditya, llvm-commits
      
      Tags: #debug-info, #llvm
      
      Differential Revision: https://reviews.llvm.org/D70604
      2de23c83
  23. Nov 22, 2019
    • Tsang Whitney W.H's avatar
      [CodeMoverUtils] Added an API to check if an instruction can be safely · ae8a8c2d
      Tsang Whitney W.H authored
      moved before another instruction.
      Summary:Added an API to check if an instruction can be safely moved
      before another instruction. In future PRs, we will like to add support
      of moving instructions between blocks that are not control flow
      equivalent, and add other APIs to enhance usability, e.g. moving basic
      blocks, moving list of instructions...
      Loop Fusion will be its first user. When there is intervening code in
      between two loops, fusion is currently unable to fuse them. Loop Fusion
      can use this utility to check if the intervening code can be safely
      moved before or after the two loops, and move them, then it can
      successfully fuse them.
      Reviewer:kbarton,jdoerfert,Meinersbur,bmahjour,etiotto
      Reviewed By:bmahjour
      Subscribers:mgorny,hiraditya,llvm-commits
      Tag:LLVM
      Differential Revision:https://reviews.llvm.org/D70049
      ae8a8c2d
  24. Nov 12, 2019
  25. Nov 09, 2019
  26. Nov 08, 2019
  27. Nov 07, 2019
  28. Nov 05, 2019
  29. Nov 04, 2019
  30. Oct 31, 2019
  31. Oct 28, 2019
Loading