Thread (99 messages) 99 messages, 10 authors, 2021-06-14

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

From: Peter Zijlstra <peterz@infradead.org>
Date: 2021-06-14 09:01:55
Also in: linux-kbuild, lkml

On Sat, Jun 12, 2021 at 01:56:41PM -0700, Bill Wendling wrote:
On Sat, Jun 12, 2021 at 1:25 PM Peter Zijlstra [off-list ref] wrote:
quoted
On Sat, Jun 12, 2021 at 12:10:03PM -0700, Bill Wendling wrote:
Yes it is, but is that sufficient in this case? It very much isn't for
KASAN, UBSAN, and a whole host of other instrumentation crud. They all
needed their own 'bugger-off' attributes.
quoted
quoted
We've got KCOV and GCOV support already. Coverage is also not an
argument mentioned anywhere else. Coverage can go pound sand, we really
don't need a third means of getting that.
Those aren't useful for clang-based implementations. And I like to
look forward to potential improvements.
I look forward to less things doing the same over and over. The obvious
solution if of course to make clang use what we have, not the other way
around.
That is not the obvious "solution".
Because having GCOV, KCOV and PGO all do essentially the same thing
differently, makes heaps of sense?

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

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.

Note that if your compiler does arcs with functions (like gcc, unlike
clang) we can also trivially augment the arcs with PMU counter data. I
once did that for userspace.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help