> -----Original Message-----
> From: Prathamesh Kulkarni <[email protected]>
> Sent: 31 October 2025 00:44
> To: Prathamesh Kulkarni <[email protected]>; gcc-
> [email protected]; Jan Hubicka <[email protected]>
> Subject: RE: [RFC] Enable time profile function reordering with
> AutoFDO
>
>
>
> > -----Original Message-----
> > From: Prathamesh Kulkarni <[email protected]>
> > Sent: 23 October 2025 10:39
> > To: [email protected]; Jan Hubicka <[email protected]>
> > Subject: RE: [RFC] Enable time profile function reordering with
> > AutoFDO
> >
> > External email: Use caution opening links or attachments
> >
> >
> > > -----Original Message-----
> > > From: Prathamesh Kulkarni <[email protected]>
> > > Sent: 13 October 2025 20:25
> > > To: Prathamesh Kulkarni <[email protected]>; gcc-
> > > [email protected]; Jan Hubicka <[email protected]>
> > > Subject: RE: [RFC] Enable time profile function reordering with
> > > AutoFDO
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Prathamesh Kulkarni <[email protected]>
> > > > Sent: 06 October 2025 19:41
> > > > To: [email protected]; Jan Hubicka <[email protected]>
> > > > Subject: [RFC] Enable time profile function reordering with
> > AutoFDO
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > Hi Honza,
> > > > The attached patch enables time profile based reordering with
> > > AutoFDO
> > > > with -fauto-profile -fprofile-reorder-functions, by mapping
> > > timestamps
> > > > obtained from perf into node->tp_first_run, and is based on top
> of
> > > > Dhruv's sourcefile tracking patch:
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2025-
> > September/694800.html
> > > >
> > > > The rationale for doing this is:
> > > > (1) GCC already implements time-profile function reordering, the
> > > patch
> > > > enables it with AutoFDO.
> > > > (2) While time profile ordering is primarily meant for
> optimizing
> > > > startup time, we've also observed good effects on code-locality
> > for
> > > > large internal workloads.
> > > > (3) Possibly useful for function reordering when accurate
> profile
> > > > annotation is hard with AutoFDO -- For eg, if branch samples are
> > > > missing (due to absence of LBR like structure).
> > > >
> > > > On AutoFDO tools side, I have a patch that extends gcov to emit
> > 64-
> > > bit
> > > > perf timestamp that records first execution of function, which
> > > loosely
> > > > corresponds to PGO's time_profile counter.
> > > > The timestamp is stored adjacent to head field in toplevel
> > function
> > > > info.
> > > > I will post a patch for this shortly on AutoFDO tools upstream
> > repo.
> > > >
> > > > On GCC side, the patch makes the following changes:
> > > >
> > > > (1) Changes to auto-profile pass:
> > > > The patch adds a new field timestamp to function_instance, and
> > > > populates it in read_function_instance.
> > > >
> > > > It maintains a new timestamp_info_map from timestamp -> <name,
> > > > tp_first_run>, which maps timestamps sorted in ascending order
> to
> > > > (1..N), so lowest ordered timestamp is mapped to 1 and so on.
> The
> > > > rationale for this is that timestamps are 64-bit integers, and
> we
> > > > don't need the full 64-bit range for ordering by tp_first_run.
> > > >
> > > > During annotation, the timestamp associated with
> function_instance
> > > is
> > > > looked up in timestamp_info_map, and corresponding mapped value
> is
> > > > assigned to node->tp_first_run.
> > > >
> > > > (2) Handling clones:
> > > > Currently, for clones not registered in call graph before auto-
> > > profile
> > > > pass, the tp_first_run field is copied from original function,
> > when
> > > > the clone is created.
> > > > However that may not correspond to the actual order of
> functions.
> > > >
> > > > For eg, if we have two profiled clones of foo:
> > > > foo.constprop.1, foo.constprop.2
> > > >
> > > > both will get same value for tp_first_run as foo->tp_first_run,
> > > which
> > > > might not correspond to time profile order.
> > > >
> > > > To address this, the patch introduces a new IPA pass
> > > > ipa_adjust_tp_first_run, that streams <clone name, tp_first_run>
> > > from
> > > > timestamp_info_map during LGEN, and during WPA reads it, and
> sets
> > > > clone's tp_first_run field accordingly.
> > > > The pass is placed pretty late (just before locality_cloning),
> by
> > > that
> > > > point clones would be registered in the call graph.
> > > >
> > > > Dhruv's sourcefile tracking patch already handles LTO privatized
> > > > functions.
> > > > The patch adds a (temporary) workaround for functions with
> > > > mismatched/empty filenames from gcov, to avoid getting dropped
> in
> > > > afdo_annotate_cfg by iterating thru all filenames in
> > > afdo_string_table
> > > > if get_function_instance_by_decl fails to find function_instance
> > > with
> > > > lbasename (DECL_SOURCE_FILE (decl)).
> > > >
> > > > (3) Grouping profiled functions together in as few partitions as
> > > > possible (preferably single).
> > > > The patch places profiled functions in time profile order
> together
> > > in
> > > > as few paritions as possible to get better advantage of code
> > > locality.
> > > > Unlike PGO, where every instrumented function gets a time
> profile
> > > > counter, with AutoFDO, the sampled functions are a fraction of
> the
> > > > total executed ones.
> > > > Similarly, in default_function_section, it overrides hot/cold
> > > > partitioning so that grouping of profiled functions isn't
> > disrupted.
> > > >
> > > > (4) Option to disable profile driven opts.
> > > > The patch adds option -fauto-profile-reorder-only which only
> > enables
> > > > time-profile reordering with AutoFDO (and disables profile
> driven
> > > > opts):
> > > > (a) Useful as a debugging aid to isolate regression to either
> > > function
> > > > reordering or profile driven opts.
> > > > (b) For our use case, it's also seemingly useful as a stopgap
> > > measure
> > > > to avoid regressions with AutoFDO profile driven opts, due to
> > issues
> > > > with profile quality obtained with merging of SPE and non SPE
> > > > profiles.
> > > > We're actively working on resolving this.
> > > > (c) Possibly useful for architectures which do not support
> branch
> > > > sampling.
> > > > The option is disabled by default.
> > > >
> > > > Ideally, I would like to make it a param (and not user facing
> > > option),
> > > > but I am not able to control enabling/disabling options in
> > > > opts.cc:common_handle_option based on param value, will
> > investigate
> > > > this further.
> > > >
> > > > * Results
> > > >
> > > > On one large interal workload, the patch (along with sourcefile
> > > > tracking patch), gives an uplift of 32.63% compared to LTO, and
> > > 8.07%
> > > > compared to LTO + AutoFDO trunk, and for another workload it
> gives
> > > an
> > > > uplift of 15.31% compared to LTO, and 7.76% compared to LTO +
> > > AutoFDO
> > > > trunk.
> > > > I will try benchmarking with SPEC2017.
> > > >
> > > > Will be grateful for suggestions on how to proceed further.
> > > Hi,
> > > ping: https://gcc.gnu.org/pipermail/gcc-patches/2025-
> > > October/696758.html
> > Hi,
> > ping * 2: https://gcc.gnu.org/pipermail/gcc-patches/2025-
> > October/696758.html
> Hi,
> ping * 3: https://gcc.gnu.org/pipermail/gcc-patches/2025-
> October/696758.html
Hi,
ping * 4: https://gcc.gnu.org/pipermail/gcc-patches/2025-October/696758.html
Thanks,
Prathamesh
>
> Thanks,
> Prathamesh
> >
> > Thanks,
> > Prathamesh
> > >
> > > Thanks,
> > > Prathamesh
> > > >
> > > > Signed-off-by: Prathamesh Kulkarni <[email protected]>
> > > >
> > > > Thanks,
> > > > Prathamesh
