Couple of general questions about PGO

IR & Optimizations
,
1

Hi all ,

I started to look into PGO for a project and a few questions came to mind.

  1. Why the recommendation is to use IR-PGO(fprofile-generate) instead of FE-PGO(fprofile-instr-generate)?
    I understand that FE-PGO is based on AST-instrumentation where IR-PGO is based on CFG-instrumentation, so there are less counter updates in IR-PGO, so it seems reasonable to use IR-PGO to reduce the runtime of the instrumented program but performance-wise there is a difference between the two ? IR-PGO can do a better job optimizing the code than FE-PGO ? why ?

  2. I saw that there is a discussion to deprecate FE-PGO (Status of IR vs. frontend PGO).
    Do you know maybe what is the status about it ?

  3. Why deprecate FE-PGO in the first place if it needed for code coverage ?
    It seems to me that IR-PGO is less resilient to compiler changes then FE-PGO ,because it depends on CFG where it seems to me that AST is more stable.
    So if the compiler is used by internal users that keep the compiler version updated frequently , it might be more reasonable for them to use FE-PGO and not IR-PGO.

Thanks a lot

2

Thanks for linking the discussion on deprecating FE-PGO, I hadn’t read it before. There were some claims that IRPGO profiles lead to better performance (Status of IR vs. frontend PGO (fprofile-generate vs fprofile-instr-generate) - #3 by rnk), but it would be nice to see a more thorough investigation. Some comments also pointed out that IRPGO has more features than FE-PGO. Here’s a list off the top of my head:

1 Like
3

I am not the best expert here, but I think the simple reason is that, to do PGO well, you want to instrument and apply branch weights after inlining to make sure your counters and branch weights are as context sensitive as possible. Conditional branches in inlined functions may do radically different things in different inlined call sites, and you get worse results if you can only apply weights to the original branch generated by the frontend.

The secondary reason is that IR PGO gets more investment. All the features you mentioned are good examples of investment. This is what Google uses and where it applies its effort. The lightweight instrumentation mode is a contribution from Meta.

Anyone can put together a more thorough investigation comparing the two PGO modes, but it’s quite a bit of work. We shared the results we got at the time on Chromium (11% vs 17%), but didn’t take the investigation further.

1 Like