public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Martin Liška" <mliska@suse.cz>
To: Richard Biener <richard.guenther@gmail.com>,
	Xinliang David Li <davidxl@google.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>, Jan Hubicka <hubicka@ucw.cz>,
	Eugene Rozenfeld <Eugene.Rozenfeld@microsoft.com>
Subject: Re: State of AutoFDO in GCC
Date: Fri, 23 Apr 2021 09:18:22 +0200	[thread overview]
Message-ID: <deba67cc-f2c1-8573-3b1f-fd7f1bf8b66e@suse.cz> (raw)
In-Reply-To: <CAFiYyc07xORMtH=mQVQu8z4+34YmZhjiy70krh6m945gqKQXWA@mail.gmail.com>

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.

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
>>>>>
>>>>
>>>


  reply	other threads:[~2021-04-23  7:18 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-22 19:58 Eugene Rozenfeld
2021-04-22 20:16 ` Martin Liška
2021-04-22 22:29   ` Jan Hubicka
2021-04-23  4:14     ` Xinliang David Li
2021-04-23  7:00       ` Richard Biener
2021-04-23  7:18         ` Martin Liška [this message]
2021-04-23  9:32           ` Richard Biener
2021-04-23 16:41           ` Xinliang David Li
2021-04-23 16:54             ` Jan Hubicka
2021-04-23 17:04               ` Xinliang David Li
2021-04-23 17:16                 ` Jan Hubicka
2021-04-23 17:27                   ` Xinliang David Li
2021-04-23 17:28                     ` Xinliang David Li
2021-04-23 19:28                       ` Jan Hubicka
2021-04-23 19:58                         ` Xinliang David Li
2021-04-25 19:07                           ` Jan Hubicka
2021-04-25 23:18                             ` Xinliang David Li
2021-04-26  4:22                               ` Wei Mi
2021-04-26 15:11                             ` Andi Kleen
2021-04-26 16:57                               ` Xinliang David Li
2021-04-26 18:00                                 ` Andi Kleen
2021-04-26 18:05                                   ` Xinliang David Li
2021-04-26 18:40                                     ` Hongtao Yu
2021-04-26 19:13                                       ` Andi Kleen
2021-04-29  5:40                                       ` Andi Kleen
2021-04-29 14:45                                         ` 172060045
2021-04-30 21:43                                           ` Andi Kleen
2021-05-08 11:25                                             ` 172060045
2021-05-09 16:28                                               ` Andi Kleen
2021-05-09 17:01                                                 ` Jan Hubicka
2021-05-10 15:36                                                   ` Andi Kleen
2021-05-10 16:55                                                     ` Joseph Myers
2021-05-10 17:21                                                       ` Andi Kleen
2022-07-26 20:12                                                         ` Eugene Rozenfeld
2022-07-26 22:37                                                           ` David Edelsohn
2022-07-27  7:26                                                             ` Jan Hubicka
2022-07-27 18:30                                                               ` [EXTERNAL] " Eugene Rozenfeld
2022-07-27 18:24                                                             ` Eugene Rozenfeld
2022-07-27  1:31                                                           ` Xionghu Luo
2022-07-27  1:41                                                             ` Xionghu Luo
2022-07-27 18:38                                                               ` [EXTERNAL] " Eugene Rozenfeld
2021-05-10 23:46                                         ` Wei Mi
2021-05-22  1:28                                           ` [EXTERNAL] " Eugene Rozenfeld
2021-05-22 16:36                                             ` Wei Mi
2021-05-25  1:39                                               ` Eugene Rozenfeld
2021-05-25  3:11                                                 ` Wei Mi
2021-05-25  3:33                                                   ` Eugene Rozenfeld
2021-05-25  3:54                                                     ` Wei Mi
2021-05-25  7:01                                                       ` Eugene Rozenfeld
2021-05-25 16:16                                                         ` Wei Mi
2021-05-25 20:49                                                           ` Eugene Rozenfeld
2021-05-26  3:06                                                             ` Wei Mi
2021-05-26 23:39                                                               ` Eugene Rozenfeld
2021-05-27  2:51                                                                 ` Wei Mi
2021-06-12  1:14                                                                   ` Eugene Rozenfeld
2021-06-14 17:00                                                                     ` Wei Mi
2021-04-23 17:20           ` Jan Hubicka
2021-04-23 16:36         ` Xinliang David Li
2021-04-30 18:48           ` [EXTERNAL] " Eugene Rozenfeld
2021-04-30 21:45             ` Andi Kleen
2021-06-24 21:45               ` Eugene Rozenfeld
2021-04-23  1:46   ` Bin.Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=deba67cc-f2c1-8573-3b1f-fd7f1bf8b66e@suse.cz \
    --to=mliska@suse.cz \
    --cc=Eugene.Rozenfeld@microsoft.com \
    --cc=davidxl@google.com \
    --cc=gcc@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).