This is an archive of the discontinued LLVM Phabricator instance.

[BranchFolding] Salvage DBG_VALUE instructions from empty blocks
ClosedPublic

Authored by bjope on Apr 27 2018, 5:35 AM.

Details

Summary

This patch will introduce copying of DBG_VALUE instructions
from an otherwise empty basic block to predecessor/successor
blocks in case the empty block is eliminated/bypassed. It
is currently only done in one identified situation in the
BranchFolding pass, before optimizing on empty block.
It can be seen as a light variant of the propagation done
by the LiveDebugValues pass, which unfortunately is executed
after the BranchFolding pass.

We only propagate (copy) DBG_VALUE instructions in a limited
number of situations:
a) If the empty BB is the only predecessor of a successor

we can copy the DBG_VALUE instruction to the beginning of
the successor (because the DBG_VALUE instruction is always
part of the flow between the blocks).

b) If the empty BB is the only successor of a predecessor

we can copy the DBG_VALUE instruction to the end of the
predecessor (because the DBG_VALUE instruction is always
part of the flow between the blocks). In this case we add
the DBG_VALUE just before the first terminator (assuming
that the terminators do not impact the DBG_VALUE).

A future solution, to handle more situations, could perhaps
be to run the LiveDebugValues pass before branch folding?

This fix is related to PR37234. It is expected to resolve
the problem seen, when applied together with the fix in
SelectionDAG from here: https://reviews.llvm.org/D46129

Diff Detail

Event Timeline

bjope created this revision.Apr 27 2018, 5:35 AM

Have you thought about just changing the scheduling of the LiveDebugValues pass to run earlier instead? Would that be an overall improvement?

ormris added a subscriber: ormris.Apr 27 2018, 9:29 AM
bjope added a comment.Apr 27 2018, 9:31 AM

Have you thought about just changing the scheduling of the LiveDebugValues pass to run earlier instead? Would that be an overall improvement?

Not more than mentioned in the summary:
"A future solution, to handle more situations, could perhaps be to run the LiveDebugValues pass before branch folding?"

I think it would be an interesting thing to test. Does anybody know if there are some known restrictions, explaining why the LiveDebugValues pass is run so late today?

I see one potential risk with populating the code with lots of DBG_VALUE instructions not really related to the preceeding MI.
Currently a DBG_VALUE basically follows the preceeding MI around when scheduling in our out-of-tree VLIW-scheduler (I think it is quite similar with the in-tree MIScheduler). So if there are lots of DBG_VALUE instructions that aren't describing what happened in the preceeding instruction, then the result after scheduling will be bad. So scheduling is a major problem for us when it comes to debug-info. We do MI scheduling late in the pipeline, including VLIW bundling and we haven't yet found a way to teach the scheduler how to handle debug-info properly, while still ignoring debug-info since the codegen should be the same with and without debug-info.

aprantl accepted this revision.Apr 27 2018, 10:01 AM

Thanks for the analysis! It sounds like running LiveDebugValues after MI scheduling is the right way to go at this point in time. Assuming that scheduling happens after branch folding, let's do this patch for now. Also, LiveDebugValues wouldn't do the kind of backwards propagation that you are doing here, so I'd consider this a cheap enabler for LiveDebugValues to be more effective.

lib/CodeGen/BranchFolding.cpp
1392

ditto

1397

s/should be possible/ is legal/

This revision is now accepted and ready to land.Apr 27 2018, 10:01 AM
This revision was automatically updated to reflect the committed changes.