This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH AutoFDO]Restoring indirect call value profile transformation
- From: Andi Kleen <ak at linux dot intel dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: "Amker.Cheng" <amker dot cheng at gmail dot com>, bin dot cheng at linux dot alibaba dot com, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 19 Dec 2018 09:42:57 -0800
- Subject: Re: [PATCH AutoFDO]Restoring indirect call value profile transformation
- References: <email@example.com> <firstname.lastname@example.org> <CAHFci28x7Gt7=0mViO_PqzN0RPqPho69SER94LEzKoCa8HovRA@mail.gmail.com> <CAHFci28+4fboT+-+=ainVpbM+ufqt+uoawpS8754fcXsgzORBQ@mail.gmail.com> <20181219040035.GO25620@tassilo.jf.intel.com> <CAHFci2_7Nh=ZrHLpT4KpBHdN-HQL+uD9XzjPWkCO4D4JrjwXNA@mail.gmail.com> <CAFiYyc22ApfZ5Wvk6U2+rAP6a0WhvioWaSg9PvbA=tJLfCLwpQ@mail.gmail.com> <20181219154112.GP25620@tassilo.jf.intel.com> <CAFiYyc2kd=uyFwPut0j5YDVY8YXVF20K3beUghDQ261z67YsDA@mail.gmail.com>
On Wed, Dec 19, 2018 at 06:28:29PM +0100, Richard Biener wrote:
> On Wed, Dec 19, 2018 at 4:41 PM Andi Kleen <email@example.com> wrote:
> > > > We can combine the two together, increasing iteration count and
> > > > decreasing perf count at the same time. What count would you suggest
> > > > from your experience?
> > >
> > > Can we instead for the tests where we want to test profile use/merge
> > > elide the profiling step and supply the "raw" data in an testsuite alternate
> > > file instead?
> > That would be possible, but a drawback is that we wouldn't have an
> > "end2end" test anymore that also tests the interaction with perf
> > and autofdo. Would be good to test these cases too, there were regressions
> > in this before.
> > But perhaps splitting that into two separate tests is reasonable,
> > with the majority of tests running with fake data.
> > This would have the advantage that gcc developers who don't
> > have an autofdo setup (e.g. missing tools or running in virtualization
> > with PMU disabled) would still do most of the regression tests.
> Yes, I think the pros outweight the cons here. Well, at least if
> generating such data that works on multiple archs is even possible?
The gcov data that comes out of autofdo is architecture independent
as far as I know. It's mainly counts per line.
In fact even the perf input data should be fairly architecture
independent (except perhaps for endian)
I think it would need a way to write gcov data using text input
(unless you want to put a lot of binaries into the repository)
Also it would need to be adjusted every time a line number
changes in the test cases. I guess best would be if dejagnu
could somehow generate it from test case comments, but I don't
know how complicated that would be.
Doing such updates would be likely difficult with binaries.
In the future if we ever re-add discriminator support
again it would also need some way to specify the correct
I guess for simple test cases it could be ensured it is