dump_gcov shows inlined_function is at wrong offset number

[algebra84]

I'm trying to enable autofdo for SPEC2017 508.namd_r with -march=x86-64-v3 -O2 -g GCC15.0.1 20250117, and notice there's 5% regression.
With GDB, I found GCC autoprofile cannot get inlined function instance with get_function_instance_by_inline_stack, and failed
afdo_callsite_hot_enough_for_early_inline. So I looked at the dump from dump_gcov, and find the offset of the inlined function is wrong. I tried with create_llvm_prof with --format=text --out=my_profile. and surprisely saw it's correct here(perf.data is same).
So with same perf.data

 create_gcov --binary=./namd_r_base.march_v3_o2_g --profile=./perf.data -gcov_version=2 --gcov=./namd_r_base.march_v3_o2_g.gcov

 dump_gcov ./namd_r_base.march_v3_o2_g.gcov > namd_r_base.march_v3_o2_g.gcov_dump

create_llvm_prof --binary=./namd_r_base.march_v3_o2_g --profile=./perf.data --format=text --out=namd_r_base.march_v3_o2_g.llvm_prof_dump

in namd_r_base.march_v3_o2_g.gcov_dump, function nextlist is at offset 1090 in calc_pair, which is wrong

1090: _ZN9Pairlists8nextlistEPPtPi total:15312
  1: 7656
  2: 7656
1091: _ZN9Pairlists8nextlistEPPtPi total:15312
  1: 7656
  2: 7656
1092: _ZN9Pairlists8nextlistEPPtPi total:15312
  1: 7656
  2: 7656

But in namd_r_base.march_v3_o2_g.llvm_prof_dump, function nextlist is at offset 1227 in calc_pair which is right

1227: _ZN9Pairlists8nextlistEPPtPi:52947
  1: 1572
  2: 1572
1228: _ZN9Pairlists8nextlistEPPtPi:17292
  1: 1572
  2: 1572
1229: _ZN9Pairlists8nextlistEPPtPi:29868
  1: 1572
  2: 1572
1254: _ZNK7LJTable9table_rowEj:42964

I'm not sure the problem is related to dump_gcov or create_gcov?

I'm at SPR with below system.

Operating System: Ubuntu 22.04.5 LTS
          Kernel: Linux 5.19.0-46-generic
    Architecture: x86-64

[algebra84]

Both dump_gcov/create_gcov and create_llvm_prof are built from latest code in autofdo

commit 8f9ab68921f364a6433086245ca3f19befacfeb1 (grafted, HEAD -> master, origin/master, origin/HEAD)
Author: Han Shen <shenhan@google.com>
Date:   Tue Nov 26 17:30:38 2024 -0800

    Update third_party/llvm-project to 11/26/2024 version. (#231)

    This also fixes some compilation errors due to llvm version bump.

[erozenfeld]

@algebra84 If you can you share namd_r_base.march_v3_o2_g and perf.data and also a preprocessed file and your gcc switches when invoking gcc with namd_r_base.march_v3_o2_g.gcov, I can debug this issue.

[algebra84]

Thanks for your reply, I can't provide the binary and perf.data, let me try to find an alternative way to reproduce the issue and provide to you.

[janhubicka]

Note that gcc now has -Wauto-profile which will output warning on similar mismatches. There is also tracking bug in GCC bugzilla and it would be useful to attach there things that may be bugs on GCC side.

We now run regular tests
https://lnt.opensuse.org/db_default/v4/SPEC/machine/1370
that can be compared to non-auto-fdo builds
https://lnt.opensuse.org/db_default/v4/SPEC/68665?compare_to=68677

I fixed number of issues recently. I see namd regression there too, so I will see if I get the mismatch you report.

[janhubicka]

Forgot to link autofdo trakicng bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=AutoFDO