https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121093
--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Just for bit more context, LlVM doesn't have an equivalent of debug markers and
compiles p3 as:
p3: # @p3
.Lfunc_begin0:
.file 0 "/home/jh" "e.c" md5 0x8a15ab558b0b5c239714dc4fe93e257a
.cfi_startproc
# %bb.0:
.loc 0 3 17 prologue_end # e.c:3:17
leal 3(%rdi), %eax
.Ltmp0:
.loc 0 13 9 # e.c:13:9
retq
e.c:3 is body of p1 and e.c:13 is body of p3, so it also skips p2.
To solve the auto-fdo precision problems Facebook team introduced
pseudo-probes:
https://reviews.llvm.org/D86193
In nature they are similar to our debug markers but specialized for AFDO and
they denote place in code that should be accounted as execution of given BB.
There seems to not be agreement about pseudoprobes being better then debug info
based afdo and both paths are maintained. See the discussion.
-fpseudo-probe-for-profiling does:
.cfi_startproc
# %bb.0:
# kill: def $edi killed $edi def $rdi
+ .pseudoprobe 1232252888641280679 1 0 0 p3
+ .pseudoprobe 482063686356336346 1 0 0 p3
+ .pseudoprobe 14859508731817411451 1 0 0 p3
leal 3(%rdi), %eax
retq
....
+ .section .pseudo_probe_desc,"",@progbits
+ .quad -3587235341892140165
+ .quad 562954248388607
+ .byte 2
+ .ascii "p3"
+ .quad 482063686356336346
+ .quad 4294967295
+ .byte 54
+ .ascii "_ZL2p1i.__uniq.332962927259486119284076767857915071854"
+ .quad 1232252888641280679
+ .quad 4294967295
+ .byte 54
+ .ascii "_ZL2p2i.__uniq.332962927259486119284076767857915071854"
+ .quad -2624081020897602054
+ .quad 281582264815352
So it essentially adds the marker for all 3 basic blocks pointing to p3, p1 and
p2, which I think we can achieve by debug statements hopefully both improving
debug info quality and getting afdo precise enough.
