[llvm-dev] [InstrProfiling] Lightweight Instrumentation

[Ellis Hoag via llvm-dev]

Hi David,

Thanks for the feedback! I'm happy to see interest in improving
instrumentation size in upstream LLVM.

As for detecting CFG mismatches with __llvm_prf_data, we can easily store
the cfg hash in Dwarf using the DW_TAG_LLVM_annotation attribute which can
store any link-time constant. This value would be included final
default.profdata profile without any format change, so the compile would
consume it in the same way.

Ellis

On Mon, Oct 18, 2021 at 12:30 PM Xinliang David Li <davidxl at google.com>
wrote:

> 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/ba9cd100/attachment.html>