Re: [AutoFDO] prevent head_count of 0 with AFDO profile.

Kugan,
I apologize for late reaction. I finally got to reproduce this.
I think we want to set the entry block count to
 MAX (1, afdo_count_scale / 2)
Receiving 0 samples on code that is known to be executed means that the
real value should be somewhere between 0 and 1, so 1/2 is good
estimate.  Setting
count 1 will make all basic blocks to appear very hot and confuse the logic
computing BB frequency.

Also I think you can do that just once in  afdo_calculate_branch_prob
just after calling afdo_adjust_guessed_profile instead of doing it as a
part of the fixup algorithm (which is already bit complicated).

This will also create bit inconsistent profile as the successor of entry
block (actual first block of the function) will likely also have 0 count,
but I hope this is not that important in practice as this should only
happen for functions that has been inlined.

thanks,
Honza

On Tue, Jul 21, 2026 at 8:10 AM Kugan Vivekanandarajah <
[email protected]> wrote:

> Ping?
>
> Thanks,
> Kugan
>
> > On 16 Jun 2026, at 8:25 pm, Kugan Vivekanandarajah <
> [email protected]> wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Ping?
> >
> > Thanks,
> > Kugan
> >
> >> On 2 Jun 2026, at 11:16 am, Kugan Vivekanandarajah <
> [email protected]> wrote:
> >>
> >> External email: Use caution opening links or attachments
> >>
> >>
> >> Ping?
> >>
> >> Thanks
> >> Kugan
> >>
> >>> On 19 May 2026, at 10:30 am, Kugan Vivekanandarajah <
> [email protected]> wrote:
> >>>
> >>> External email: Use caution opening links or attachments
> >>> Hi,
> >>>
> >>> This is another attempt to prevent head_count of 0 with AFDO profile.
> This is causing ICE with LTO:
> >>>
> >>> during IPA pass: modref
> >>> lto1: internal compiler error: in apply_scale, at profile-count.h:1192
> >>> 0x2292433 internal_error(char const*, ...)
> >>>
> /var/jenkins/workspace/GCC_oss-main/gcc/diagnostic-global-context.cc:787
> >>> 0x8a2ba7 fancy_abort(char const*, int, char const*)
> >>> /var/jenkins/workspace/GCC_oss-main/gcc/diagnostics/context.cc:1813
> >>> 0x98efcf profile_count::apply_scale(profile_count, profile_count) const
> >>> /var/jenkins/workspace/GCC_oss-main/gcc/profile-count.h:1192
> >>> 0xd2536f ipa_merge_profiles(cgraph_node*, cgraph_node*, bool)
> >>> /var/jenkins/workspace/GCC_oss-main/gcc/ipa-utils.cc:637
> >>> 0x8fc01b lto_symtab_merge_symbols_1
> >>> /var/jenkins/workspace/GCC_oss-main/gcc/lto/lto-symtab.cc:934
> >>> 0x8fc01b lto_symtab_merge_symbols()
> >>> /var/jenkins/workspace/GCC_oss-main/gcc/lto/lto-symtab.cc:996
> >>> 0x90b7f7 read_cgraph_and_symbols(unsigned int, char const**)
> >>> /var/jenkins/workspace/GCC_oss-main/gcc/lto/lto-common.cc:3003
> >>> 0x8e8abf lto_main()
> >>> /var/jenkins/workspace/GCC_oss-main/gcc/lto/lto.cc:663 <
> http://lto.cc:663/>
> >>>
> >>>
> >>>
> >>> When afdo_adjust_guessed_profile runs scale_bbs, the entry block can be
> >>> scaled to 0 (auto FDO) while inner basic blocks keep nonzero AFDO
> >>> counts.
> >>>
> >>> Example from profile annotation (stats.ii, _M_get_insert_unique_pos):
> >>> ... total:264 head:-1
> >>> bb 0 count updated 118111600 (estimated locally) -> 0 (auto FDO)
> >>> Example ICE at LTO (WPA merge of comdat clones):
> >>> Merging profiles of _M_get_insert_unique_pos/10 count:64711123189
> >>> (auto FDO)
> >>>                     to _M_get_insert_unique_pos/1 count:0 (auto FDO)
> >>> during IPA pass: modref
> >>> lto1: internal compiler error: in apply_scale, at profile-count.h:1192
> >>>   ipa_merge_profiles (dstnum, dstden)
> >>>
> >>> Fix by calling afdo_fixup_entry_after_scale immediately after each
> >>> scale_bbs in afdo_adjust_guessed_profile when max_count_in_fn is
> nonzero
> >>> but the entry block count is still zero.
> >>>
> >>> gcc/ChangeLog:
> >>> * auto-profile.cc (afdo_fixup_entry_after_scale): New.
> >>> (afdo_adjust_guessed_profile): Call it after scale_bbs.
> >>>
> >>> Regression tested on aarch64-linux-gnu with no new regressions. Is
> this OK for trunk?
> >>>
> >>> Thanks,
> >>> Kugan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> <0001-AutoFDO-Do-not-leave-entry-block-at-zero-after-guess.patch>
> >>
> >
>
>