> -----Original Message-----
> From: Prathamesh Kulkarni <[email protected]>
> Sent: 28 January 2026 07:29
> To: Prathamesh Kulkarni <[email protected]>; gcc-
> [email protected]; Jan Hubicka <[email protected]>
> Subject: RE: [RFC][Enable time profile function reordering with
> AutoFDO] Introduce pass ipa_adjust_tp_first_run for handling profiled
> clones
>
>
>
> > -----Original Message-----
> > From: Prathamesh Kulkarni <[email protected]>
> > Sent: 16 January 2026 19:11
> > To: [email protected]; Jan Hubicka <[email protected]>
> > Subject: RE: [RFC][Enable time profile function reordering with
> > AutoFDO] Introduce pass ipa_adjust_tp_first_run for handling
> profiled
> > clones
> >
> > External email: Use caution opening links or attachments
> >
> >
> > > -----Original Message-----
> > > From: Prathamesh Kulkarni <[email protected]>
> > > Sent: 05 January 2026 16:34
> > > To: Prathamesh Kulkarni <[email protected]>; gcc-
> > > [email protected]; Jan Hubicka <[email protected]>
> > > Subject: RE: [RFC][Enable time profile function reordering with
> > > AutoFDO] Introduce pass ipa_adjust_tp_first_run for handling
> > profiled
> > > clones
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Prathamesh Kulkarni <[email protected]>
> > > > Sent: 23 December 2025 16:16
> > > > To: [email protected]; Jan Hubicka <[email protected]>
> > > > Subject: [RFC][Enable time profile function reordering with
> > AutoFDO]
> > > > Introduce pass ipa_adjust_tp_first_run for handling profiled
> > clones
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > Hi Honza,
> > > > The attached patch is split from the original patch and
> introduces
> > > new
> > > > pass ipa_adjust_tp_first_run for setting tp_first_run for clones
> > > that
> > > > are materialized after auto-profile pass.
> > > >
> > > > I tried using function_summary instead of custom std::map<const
> > char
> > > > *, int, string_compare> clone_timestamp_map, but am running into
> > > > following issue:
> > > > AFAIU, function_summary works as a map from cgraph_node to the
> > > custom
> > > > pass summary. But in this case, we want summary <name,
> > tp_first_run>
> > > > for node's profiled clones (and not node itself), which would
> > later
> > > > get materialized during WPA and do not exist during
> > generate_summary
> > > > stage of the pass.
> > > >
> > > > I suppose we could maintain per each node summaries of all it's
> > > > profiled clones (name, tp_first_run) during generate_summary
> > stage,
> > > > and during WPA stage of pass, fetch the correct clone from it's
> > name
> > > > and set it's tp_first_run ?
> > > > Altho if the original node gets removed from symtab during IPA
> > opts,
> > > I
> > > > am not sure if we could access it's clones info from
> > > function_summary
> > > > in the pass ?
> > > >
> > > > In the attached patch, I have left clone_timestamp_map as-is.
> > > > Could you please suggest how to proceed ?
> > > >
> > > > On average with this patch, I am seeing a ~2.5% uplift on top of
> > > base
> > > > patch (and the explicit partitioner based on tp_first_run).
> > > Hi,
> > > ping: https://gcc.gnu.org/pipermail/gcc-patches/2025-
> > > December/704417.html
> > Hi,
> > ping * 2: https://gcc.gnu.org/pipermail/gcc-patches/2025-
> > December/704417.html
> Hi,
> ping * 3: https://gcc.gnu.org/pipermail/gcc-patches/2025-
> December/704417.html
Hi,
ping * 4: https://gcc.gnu.org/pipermail/gcc-patches/2025-December/704417.html
Thanks,
Prathamesh
>
> Thanks,
> Prathamesh
> >
> > Thanks,
> > Prathamesh
> > >
> > > Thanks,
> > > Prathamesh
> > > >
> > > > Signed-off-by: Prathamesh Kulkarni <[email protected]>
> > > >
> > > > Thanks,
> > > > Prathamesh
