This is the mail archive of the
gcc-patches@gcc.gnu.org
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 07:41:12 -0800
- Subject: Re: [PATCH AutoFDO]Restoring indirect call value profile transformation
- References: <ae294d36-bc14-4407-8ce0-2f01fc3f651c.bin.cheng@linux.alibaba.com> <87wooai8cs.fsf@linux.intel.com> <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>
> > 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.
-Andi