Re: State of AutoFDO in GCC

[Richard Biener <richard.guenther@gmail.com>]

On Fri, Apr 23, 2021 at 9:18 AM Martin Liška <mliska@suse.cz> wrote:
>
> On 4/23/21 9:00 AM, Richard Biener via Gcc wrote:
> > On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc
> > <gcc@gcc.gnu.org> wrote:
> >>
> >> Hi, the create_gcov tool was probably removed with the assumption that it
> >> was only used with Google GCC branch, but it is actually used with GCC
> >> trunk as well.
> >>
> >> Given that, the tool will be restored in the github repo. It seems to build
> >> and work fine with the regression test.
> >>
> >> The tool may ust work as it is right now, but there is no guarantee it
> >> won't break in the future unless someone in the GCC community tries to
> >> maintain it.
>
> Hi.
>
> The current situation is that AutoFDO doesn't work with pretty simple test-cases
> we have in testsuite:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71672
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81379
>
> These are ~5 years old and nothing has happened.
>
> I'm pretty sure the current autofdo can't emit a .gcda file format that
> I've changed in the recent years.
>
> >
> > I think if we want to keep the feature it makes sense to provide create_gcov
> > functionality either directly from perf (input data producer) or from gcc
> > (data consumer).  Of course I have no idea about its complexity, license
> > or implementation language ...
>
> For me, it's just an i386 feature (maybe aarch64 has perf counters too?), supported
> only by vendor (Intel) and I'm not planning working on that.
> I don't like having a feature that is obviously broken and potential GCC users get
> bad experience every time they try to use it.
>
> Can we at least deprecate the feature for GCC 11? If these is enough interest,
> we can fix it, if not, I would remove it in GCC 13 timeframe.

I have no opinion here and I'm not opposed to ripping out the feature
from GCC 12.
Since it doesn't work anyway there's no need for any deprecation.

Richard.

> Thoughts?
> Martin
>
> >
> > Having the tool third-party makes keeping the whole chain working more
> > difficult.
> >
> > Richard.
> >
> >> Thanks,
> >>
> >> David
> >>
> >> On Thu, Apr 22, 2021 at 3:29 PM Jan Hubicka <hubicka@ucw.cz> wrote:
> >>
> >>>> On 4/22/21 9:58 PM, Eugene Rozenfeld via Gcc wrote:
> >>>>> GCC documentation for AutoFDO points to create_gcov tool that converts
> >>> perf.data file into gcov format that can be consumed by gcc with
> >>> -fauto-profile (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html,
> >>> https://gcc.gnu.org/wiki/AutoFDO/Tutorial).
> >>>>>
> >>>>> I noticed that the source code for create_gcov has been deleted from
> >>> https://github.com/google/autofdo on April 7. I asked about that change
> >>> in that repo and got the following reply:
> >>>>>
> >>>>> https://github.com/google/autofdo/pull/107#issuecomment-819108738
> >>>>>
> >>>>> "Actually we didn't use create_gcov and havn't updated create_gcov for
> >>> years, and we also didn't have enough tests to guarantee it works (It was
> >>> gcc-4.8 when we used and verified create_gcov). If you need it, it is
> >>> welcomed to update create_gcov and add it to the respository."
> >>>>>
> >>>>> Does this mean that AutoFDO is currently dead in gcc?
> >>>>
> >>>> Hello.
> >>>>
> >>>> Yes. I know that even basic test cases have been broken for years in the
> >>> GCC.
> >>>> It's new to me that create_gcov was removed.
> >>>>
> >>>> I tend to send patch to GCC that will remove AutoFDO from GCC.
> >>>> I known Bin spent some time working on AutoFDO, has he came up to
> >>> something?
> >>>
> >>> The GCC side of auto-FDO is not that hard.  We have most of
> >>> infrastructure in place, but stopping point for me was always difficulty
> >>> to get gcov-tool working.  If some maintainer steps up, I think I can
> >>> fix GCC side.
> >>>
> >>> I am bit unsure how important feature it is - we have FDO that works
> >>> quite well for most users but I know there are some users of the LLVM
> >>> implementation and there is potential to tie this with other hardware
> >>> events to asist i.e. if conversion (where one wants to know how well CPU
> >>> predicts the jump rather than just the jump probability) which I always
> >>> found potentially interesting.
> >>>
> >>> Honza
> >>>>
> >>>> Martin
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Eugene
> >>>>>
> >>>>
> >>>
>