Re: [PATCH v9] pgo: add clang's Profile Guided Optimization infrastructure

On Mon, Jun 14, 2021 at 3:45 AM Peter Zijlstra [off-list ref] wrote:

On Mon, Jun 14, 2021 at 02:39:41AM -0700, Bill Wendling wrote:

quoted

On Mon, Jun 14, 2021 at 2:01 AM Peter Zijlstra [off-list ref] wrote:

quoted

quoted

Because having GCOV, KCOV and PGO all do essentially the same thing
differently, makes heaps of sense?

It does when you're dealing with one toolchain without access to another.

Here's a sekrit, don't tell anyone, but you can get a free copy of GCC
right here:

  https://gcc.gnu.org/

We also have this linux-toolchains list (Cc'ed now) that contains folks
from both sides.

Your sarcasm is not useful.

quoted

quoted

I understand that the compilers actually generates radically different
instrumentation for the various cases, but essentially they're all
collecting (function/branch) arcs.

That's true, but there's no one format for profiling data that's
usable between all compilers. I'm not even sure there's a good way to
translate between, say, gcov and llvm's format. To make matters more
complicated, each compiler's format is tightly coupled to a specific
version of that compiler. And depending on *how* the data is collected
(e.g. sampling or instrumentation), it may not give us the full
benefit of FDO/PGO.

I'm thinking that something simple like:

struct arc {
        u64     from;
        u64     to;
        u64     nr;
        u64     cntrs[0];
};

goes a very long way. Stick a header on that says how large cntrs[] is,
and some other data (like load offset and whatnot) and you should be
good.

Combine that with the executable image (say /proc/kcore) to recover
what's @from (call, jmp or conditional branch) and I'm thinking one
ought to be able to construct lots of useful data.

I've also been led to believe that the KCOV data format is not in fact
dependent on which toolchain is used.

quoted

quoted

I'm thinking it might be about time to build _one_ infrastructure for
that and define a kernel arc format and call it a day.

That may be nice, but it's a rather large request.

Given GCOV just died, perhaps you can look at what KCOV does and see if
that can be extended to do as you want. KCOV is actively used and
we actually tripped over all the fun little noinstr bugs at the time.