On Mon, Jun 14, 2021 at 8:46 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Mon, Jun 14, 2021 at 08:26:01AM -0700, Kees Cook wrote: > > > 2. Like (1) but also keep GCOV, given proper support for attribute > > > no_instrument_function would probably fix it (?). > > > > > > 3. Keep GCOV (and KCOV of course). Somehow extract PGO profiles from KCOV. > > > > > > 4. Somehow extract PGO profiles from GCOV, or modify kernel/gcov to do so. > > > > If there *is* a way to "combine" these, I don't think it makes sense > > to do it now. PGO has users (and is expanding[1]), and trying to > > optimize the design before even landing the first version seems like a > > needless obstruction, and to likely not address currently undiscovered > > requirements. > > Even if that were so (and I'm not yet convinced), the current proposal > is wedded to llvm-pgo, there is no way gcc-pgo could reuse any of this > code afaict, which then means they have to create yet another variant. Similar to GCOV, the runtime support for exporting such data is heavily compiler (and compiler version) specific, as is the data format for compilers to consume. We were able to reuse most of the runtime code between GCC and Clang support in GCOV; I don't see why we couldn't do a similar factoring of the runtime code being added to the kernel here, should anyone care to pursue implementing PGO with GCC. Having an implementation is a great starting point for folks looking to extend support or to understand how to support PGO in such a bare metal environment (one that doesn't dynamically link against traditional compiler runtimes). -- Thanks, ~Nick Desaulniers
