diff options
author | Jeremy Morse <jeremy.morse@sony.com> | 2024-11-12 15:09:40 +0000 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-11-12 15:09:40 +0000 |
commit | bf483ddb42065405e345393e022dc72357ec5a3a (patch) | |
tree | 4b559e5decc186d1689c25d942552c5d7491a071 /llvm/lib/Bitcode | |
parent | eea8b44aaa3464f52dea1d56ca47e0519b08fd36 (diff) | |
download | llvm-bf483ddb42065405e345393e022dc72357ec5a3a.zip llvm-bf483ddb42065405e345393e022dc72357ec5a3a.tar.gz llvm-bf483ddb42065405e345393e022dc72357ec5a3a.tar.bz2 |
[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.
Diffstat (limited to 'llvm/lib/Bitcode')
0 files changed, 0 insertions, 0 deletions