It seems that DWARF prologue_end flag, which should be placed right after the function prologue, is often placed at the function entry point for ARM and AArch64. I filed https://llvm.org/bugs/show_bug.cgi?id=24117 about it, where I thought this was a recent regression for -O1, but in fact I found an even easier test case which reproduces this bug with basically all versions of LLVM and at -O0:
int func(void); void prologue_end_test() { func(); func(); }
compiles to (with -g -O0 -armv7):
_prologue_end_test: Lfunc_begin0: .file 1 "foo.c" .loc 1 2 0 @ foo.c:2:0 .cfi_startproc @ BB#0: @ %entry .loc 1 3 3 prologue_end @ foo.c:3:3 push {r7, lr} mov r7, sp sub sp, #8 bl _func .loc 1 4 3 @ foo.c:4:3 str r0, [sp, #4] @ 4-byte Spill bl _func ...
Obviously, the prologue isn't empty, and the prologue_end line should actually be placed before the first bl _func call.
This bug is not present on x86/x86_64. The reason why this happens is that the ARM and AArch64 backends emit line number information for the prologue's MIs. When generating the prologue, the DebugLoc from the first MI is copied to all the instructions of the prologue (but the first MI's DebugLoc can be empty in which case things are fine). The X86 backend doesn't do that and it never assigns line information to the prologue. The DWARF debug info writer attaches the prologue_end flag to the first instruction that has a non-empty debug location.
This patch changes the ARM and AArch64 prologues not to have line information.
The DebugLoc for all uses of emitSPUpdate is now just DebugLoc so you can remove the parameter.