aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Bitcode
diff options
context:
space:
mode:
authorJeremy Morse <jeremy.morse@sony.com>2024-11-12 15:09:40 +0000
committerGitHub <noreply@github.com>2024-11-12 15:09:40 +0000
commitbf483ddb42065405e345393e022dc72357ec5a3a (patch)
tree4b559e5decc186d1689c25d942552c5d7491a071 /llvm/lib/Bitcode
parenteea8b44aaa3464f52dea1d56ca47e0519b08fd36 (diff)
downloadllvm-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