On 5/4/23 14:54, Qing Zhao wrote: > > >> On May 4, 2023, at 4:30 AM, Martin Liška <mli...@suse.cz> wrote: >> >> On 5/3/23 21:10, Qing Zhao via Gcc-patches wrote: >>> Hi, Jan, >>> >>> You added the following patch into gcc10: >>> >>> From 34fbe3f0946f88828765184ed6581bda62cdf49f Mon Sep 17 00:00:00 2001 >>> From: Jan Hubicka <hubi...@ucw.cz> >>> Date: Thu, 5 Dec 2019 19:12:51 +0100 >>> Subject: [PATCH] cgraphclones.c (localize_profile): New function. >>> >>> * cgraphclones.c (localize_profile): New function. >>> (cgraph_node::create_clone): Use it for partial profiles. >>> * common.opt (fprofile-partial-training): New flag. >>> * doc/invoke.texi (-fprofile-partial-training): Document. >>> * ipa-cp.c (update_profiling_info): For partial profiles do not >>> set function profile to zero. >>> * profile.c (compute_branch_probabilities): With partial profile >>> watch if edge count is zero and turn all probabilities to guessed. >>> (compute_branch_probabilities): For partial profiles do not apply >>> profile when entry count is zero. >>> * tree-profile.c (tree_profiling): Only do >>> value_profile_transformations >>> when profile is read. >>> >>> My question is: >> >> Hello. >> >> Why would anybody backport such change to unsupported code-stream of GCC 8? >> Generally speaking, I discourage from doing that. > > Yes, I agree. > However, many users still use GCC8 right now, and some of them are asking for > more performance > from PGO recently. That’s the reason I am studying this right now.
I understand there are products that are based on GCC8, but as the branch is officially unsupported, I don't see a reason to backport a new feature from newer release. It's just asking for troubles. If your clients are interested in more performance, then they should use a recent supported release. > > From my understanding, -fprofile-partial-training is one important option for > PGO performance. I don't think so, speed benefit would be rather small I guess. > I’d like > to see any big technique difficult to prevent it from being back ported to > GCC8. There might be of course some patch dependencies and I don't see a point why should we waste time with that. Cheers, Martin > > Thanks. > > Qing > >> >> Martin >> >>> >>> Can this patch be back ported to GCC8 easily? I am wondering any significant >>> Change between GCC8 and GCC10 that might make the backporting very hard> >>> Thanks a lot for your help. >>> >>> Qing >
