[all-commits] [llvm/llvm-project] b468ed: Reapply ccddb6ffad1, "Emit a worst-case prologue_end"

[Jeremy Morse via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b468ed494acde4d1cc496a436ab9109660db5b80
      https://github.com/llvm/llvm-project/commit/b468ed494acde4d1cc496a436ab9109660db5b80
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2024-11-14 (Thu, 14 Nov 2024)

  Changed paths:
    M llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
    M llvm/test/CodeGen/X86/no-non-zero-debug-loc-prologue.ll
    M llvm/test/CodeGen/X86/pseudo_cmov_lower2.ll
    A llvm/test/DebugInfo/MIR/X86/dbg-prologue-backup-loc2.mir
    M llvm/test/DebugInfo/MIR/X86/empty-inline.mir
    A llvm/test/DebugInfo/X86/dbg-prolog-end-backup-loc.ll
    M llvm/test/DebugInfo/X86/dbg-prolog-end.ll
    M llvm/test/DebugInfo/X86/empty-line-info.ll
    M llvm/test/DebugInfo/X86/loop-align-debug.ll

  Log Message:
  -----------
  Reapply ccddb6ffad1, "Emit a worst-case prologue_end"

In 39b2979a4 Pavel has kindly refined the implementation of a test in such
a way that it doesn't trip up over this patch -- the test wishes to
stimulate LLDBs presentation of line0 locations, rather than wanting to
always step on line-zero on entry to artificial_location.c. As that's what
was tripping up this change, reapply.

Original commit message follows.

[DWARF] Emit a worst-case prologue_end flag for pathological inputs (#107849)

prologue_end usually indicates where the end of the function-initialization
lies, and is where debuggers usually choose to put the initial breakpoint
for a function. Our current algorithm piggy-backs it on the first available
source-location: which doesn't necessarily have anything to do with the
start of the function.

To avoid this in heavily-optimised code that lacks many useful source
locations, pick a worst-case "if all else fails" prologue_end location, of
the first instruction that appears to do meaningful computation. It'll be
given the function-scope line number, which should run-on from the start of
the function anyway. This means if your code is completely inverted by the
optimiser, you can at least put a breakpoint at the _start_ like you
expect, even if it's difficult to then step through.

This patch also attempts to preserve some good behaviour we have without
optimisations -- at O0, if the prologue immediately falls into a loop body
without any computation happening, then prologue_end lands at the start of
that loop. This is desirable; but does mean we need to do more work to
detect and support those situations.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications