[PATCH] D104060: Machine IR Profile

[Xinliang David Li via llvm-commits]

On Mon, Jun 14, 2021 at 11:28 AM Ellis Hoag via Phabricator <
reviews at reviews.llvm.org> wrote:

> ellis added a comment.
>
>
>
> In D104060#2815939 <https://reviews.llvm.org/D104060#2815939>, @davidxl
> wrote:
>
> > MIP has achieved great size reduction for instrumented binary. My
> > understanding the savings are mainly from the following:
> >
> > 1. Smaller counter size (1 byte or 4 byte instead of 8 byte for IR PGO)
> > 2. extractable per function metadata (mipmap). Using this technique may
> >
> > increase object file size more (due to extra relocations), but will
> reduce
> > executable size.
>
> That is correct. For function coverage MIP inject only one `movb`
> instruction in x86 so that the total overhead for every function is 1 byte
> of global data + 7 bytes of text.
>
> > I don't understand (in block coverage mode) how the .text size can be
> > reduced. I have not looked at the patch in detail, but the test case
> shows
> > that the counter update is simply a 'movb 0, $counter' even in
> non-coverage
> > mode, is that expected?
>
> Let me try to clear something up. The size tests I ran in
> https://gist.github.com/ellishg/92a68cf82bfdeccd10225154425edc69 were for
> function coverage only and block coverage disabled. For block coverage, we
> inject a single `movb` instruction and another global byte for each basic
> block so the size overhead is very similar to function coverage. Can you
> point me to the test case you are referring to?
>


I mistyped in my previous reply. I meant that I don't expect the text size
to be reduced much in the block counting mode (not coverage mode) with MIP.
I understand this is not available in MIP right now, but comparing
'function coverage mode' with 'block counting mode' is apples to oranges.

What I am getting at is that if there are not any size reduction techniques
that fundamentally must be done in MIR level, we should try to incorporate
the features into the common profiling infrastructure.  For instance,
introducing coverage mode (both function and block level) in IRPGO.

This also allows further size optimizations in the common infra in the
future. For instance, using one bit per block in coverage mode etc.

David




>
> > I think 2) is something worth introducing to IRPGO under a flag.
> >
> > David
>
>
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D104060/new/
>
> https://reviews.llvm.org/D104060
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210614/0e6db911/attachment-0001.html>