[all-commits] [llvm/llvm-project] fca410: [DebugInfo] Re-apply two patches to MachineSink

Jeremy Morse via All-commits all-commits at lists.llvm.org
Thu Dec 5 07:54:40 PST 2019


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: fca41001963cb473182c7b3b665ea1f03f94203a
      https://github.com/llvm/llvm-project/commit/fca41001963cb473182c7b3b665ea1f03f94203a
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2019-12-05 (Thu, 05 Dec 2019)

  Changed paths:
    M llvm/lib/CodeGen/MachineSink.cpp
    A llvm/test/DebugInfo/MIR/X86/machinesink.mir
    M llvm/test/DebugInfo/MIR/X86/postra-subreg-sink.mir
    A llvm/test/DebugInfo/MIR/X86/sink-leaves-undef.mir

  Log Message:
  -----------
  [DebugInfo] Re-apply two patches to MachineSink

These were:
 * D58386 / f5e1b718a67 / reverted in d382a8a768b
 * D58238 / ee50590e168 / reverted in a8db456b53a

Of which the latter has a performance regression tracked in PR43855,
fixed by D70672 / D70676, which will be committed atomically with this
reapplication.

Contains a minor difference to account for a change in the IsCopyInstr
signature.


  Commit: e4cdd6263175f7289cfb61608944892d8c76b6ff
      https://github.com/llvm/llvm-project/commit/e4cdd6263175f7289cfb61608944892d8c76b6ff
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2019-12-05 (Thu, 05 Dec 2019)

  Changed paths:
    M llvm/lib/CodeGen/MachineSink.cpp
    M llvm/test/DebugInfo/MIR/X86/machinesink.mir

  Log Message:
  -----------
  [DebugInfo] Don't reorder DBG_VALUEs when sunk

Fix part of PR43855, resolving a problem that comes from the reapplication
in 001574938e5. If we have two DBG_VALUE insts in a block that specify
the location of the same variable, for example:

   %0 = someinst
   DBG_VALUE %0, !123, !DIExpression()
   %1 = anotherinst
   DBG_VALUE %1, !123, !DIExpression()

if %0 were to sink, the corresponding DBG_VALUE would sink too, past the
next DBG_VALUE, effectively re-ordering assignments. To fix this, I've
added a SeenDbgVars set recording what variable locations have been seen in
a block already (working bottom up), and now flag DBG_VALUEs that would
pass a later DBG_VALUE for the same variable.

NB, this only works for repeated DBG_VALUEs in the same basic block, the
general case involving control flow is much harder, which I've written
up in PR44117.

Differential revision: https://reviews.llvm.org/D70672


  Commit: 30e8f80fd5a43a213f8feb124846223b61218f30
      https://github.com/llvm/llvm-project/commit/30e8f80fd5a43a213f8feb124846223b61218f30
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2019-12-05 (Thu, 05 Dec 2019)

  Changed paths:
    M llvm/lib/CodeGen/MachineSink.cpp
    M llvm/test/DebugInfo/MIR/X86/machinesink.mir

  Log Message:
  -----------
  [DebugInfo] Don't create multiple DBG_VALUEs when sinking

This patch addresses a performance problem reported in PR43855, and
present in the reapplication in in 001574938e5. It turns out that
MachineSink will (often) move instructions to the first block that
post-dominates the current block, and then try to sink further. This
means if we have a lot of conditionals, we can needlessly create large
numbers of DBG_VALUEs, one in each block the sunk instruction passes
through.

To fix this, rather than immediately sinking DBG_VALUEs, record them in
a pass structure. When sinking is complete and instructions won't be
sunk any further, new DBG_VALUEs are added, avoiding lots of
intermediate DBG_VALUE $noregs being created.

Differential revision: https://reviews.llvm.org/D70676


Compare: https://github.com/llvm/llvm-project/compare/403bb33a2e6a...30e8f80fd5a4


More information about the All-commits mailing list