This is an archive of the discontinued LLVM Phabricator instance.

[AsmPrinter] Look inside bundles and rely on FrameDestroy in calculateDbgValueHistory
Needs ReviewPublic

Authored by bjope on Aug 13 2018, 8:20 AM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

When DbgValueHistoryCalculator is determining which registers
that are clobbered within the function body it now got the
alternative to rely on FrameDestroy attributes when finding
out if an instruction is part of the epilogue or not.
In the past it treated all instructions with the same DebugLoc
as the return instruction as epilogue. So if for example the
whole function was written on a single line everything ended up
being treated as the epilogue.
For the above to work properly a target has to mark epilogue
instructions as FrameDestroy (I do not think all targets are
doing that, so therefore this isn't enabled by default).

Another difference between the old collectChangingRegs and
the new collectChangingRegsInBody is that the new method
examines individual instructions within bundles (to support
the case where a bundle contain a mix of prolog/epilog
instructions and function body instructions. That might be
an odd case, but there is nothing today that prohibits such
bundling.

Diff Detail

Event Timeline

bjope created this revision.Aug 13 2018, 8:20 AM
vsk added a subscriber: vsk.Aug 16 2018, 3:23 PM
vsk added inline comments.
include/llvm/CodeGen/TargetFrameLowering.h
286

Do you know which backends don't mark up epilog instructions with FrameDestroy? Is it feasible to fix the backends? Seems like collectChangingRegsInBody is just a more precise way of doing the job of collectChangingRegs: it'd be great to just have one copy of the logic.

bjope added inline comments.Aug 17 2018, 5:22 AM
include/llvm/CodeGen/TargetFrameLowering.h
286

Yes, the goal would be to make the hook return true in the future.

All I know right know is that turning this on by default makes lots of lit-tests fail. So even if the backend is updating FrameDestroy properly, we need to examine failing lit-tests, check if the target is using FrameDestroy, and update CHECK-statements when the result is improved.

A suggested deployment could be:

  1. Add this hook (this patch).
  2. For each in-tree target, examine if target is using FrameDestroy, if so override the hook and check/update lit-test. If not, start using FrameDestroy and override on hook.
  3. When all in-tree targets are using collectChangingRegsInBody, we can remove the old collectChangingRegs (and getFirstEpilogueInst) functions.

A possible addition to step 3 is to add an assert that isFrameSetupAndFrameDestroySupported returns true. That would give out-of-tree targets a chance to detect that they need to adapt their code somehow. And then after awhile we can remove the hook completely.

vsk added inline comments.Aug 17 2018, 11:40 AM
include/llvm/CodeGen/TargetFrameLowering.h
286

With this patch applied I just see four failing tests in check-llvm:

LLVM :: DebugInfo/AArch64/struct_by_value.ll
LLVM :: DebugInfo/X86/parameters.ll
LLVM :: DebugInfo/X86/reference-argument.ll
LLVM :: DebugInfo/X86/vla-multi.ll

It seems like the failures result from the tests being too rigid, not from really fundamental issues. It seems like it'd be less work overall to fix these now (& I'd volunteer to help with that, just fixed the vla-multi.ll test in r340068). If there are more failing tests I'm just not seeing it'd make sense to reconsider, but I'd like to avoid leaving things in a transitionary state if possible.

bjope added inline comments.Aug 22 2018, 2:55 AM
include/llvm/CodeGen/TargetFrameLowering.h
286

Ok, looks like it wasn't so many tests failing after all then. So I agree that we should try to adjust the too rigid tests first.
I'll also examine FrameLowering implementations to see if FrameDestroy is used by different targets.

It would ofcourse be nice to skip the transition state completely, but then I think we somehow should give out-of-tree targets a heads up.

jryans added a project: debug-info.
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptFeb 15 2023, 9:14 AM