[llvm-dev] [InstrProfiling] Lightweight Instrumentation

[Xinliang David Li via llvm-dev]

On Mon, Oct 18, 2021 at 1:38 PM Wenlei He <wenlei at fb.com> wrote:

> Thanks for the feedback, David.
>
>
>
> You’re right that most of the savings comes from coarse-grained
> instrumentation. However, the situation we’re facing for mobile (and also
> embedded systems) comes with very tight size constraints. Some components
> are already built with -Oz, and we’re constantly on the lookout for extra
> MiB to save so more “features” can get into the components.
>
>
>
> For clang self-build example, 7M overhead is much better than 50M+, and
> 50M->7M indeed look close to 50M->4M as improvements. But comparing to
> non-PGO, this is still +7M vs +4M. The extra 3M is considered quite
> significant, and could potentially be a deal breaker for some cases.
>
>
>
> In short, this is “close” as you mentioned, but not good enough still.
> Using dwarf as metadata also has a few benefits over tweaking existing
> metadata to be extractable: it’s less intrusive, and it’s also a more
> standardized metadata comparing to PGO’s own metadata.
>

While dwarf is a standard way of program annotation, using it for
instrumentation PGO does mean an additional dependency (instead of being
self contained).

This proposal requires debug_type info to be emitted, right? What is the
object size and compile time overhead? If this can be trimmed, it is a
reasonable way to emit the profile data mapping information at compile time.

David


>
>
> Thanks,
>
> Wenlei
>
>
>
> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Xinliang
> David Li via llvm-dev <llvm-dev at lists.llvm.org>
> *Date: *Monday, October 18, 2021 at 1:14 PM
> *To: *Ellis Hoag <ellis.sparky.hoag at gmail.com>
> *Cc: *llvm-dev <llvm-dev at lists.llvm.org>
> *Subject: *Re: [llvm-dev] [InstrProfiling] Lightweight Instrumentation
>
> Hi Ellis, thanks for the proposal. Improving the usability of
> Instrumentation PGO is indeed very important.
>
>
>
> From the results data below, if I understand correctly, the main savings
> are from supporting the coverage mode (using boolean counters), right? If
> we only enable that, the meta data based IRPGO clang size will be 10 MB
> larger (__llvm_prf_names are strippible or easily doable).
>
>
>
> About __llvm_prof_data -- it also serves the purpose of detecting CFG
> mismatch (with cfg hashing). On the other hand, about half of the size is
> used for value profiling purposes, so for coverage mode when value profile
> is not needed, its size can be cut in half -- leaving the total overhead to
> be roughly 7 MiB, very close to the debug info based matching scheme.
>
>
>
> I support the proposal related to different profiling modes (entry only,
> boolean counter).  I suggest having those features upstreamed. In addition,
> changes that can reduce existing IRPGO size (e.g, strippable name section,
> reduced __llvm_prof_data) are also very welcome. After those are done, we
> will have a better idea if the size is still an issue (with a better
> comparison with the debug info based method).
>
>
>
> thanks,
>
>
>
> David
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211018/369974fe/attachment.html>