[RFC] Adding Matching and Inference Functionality to Propeller

[wdx727]

@rlavaee

The proposal offers tolerance towards source code changes, but the experimental setup has no mention of source drift between base and AutoFDO binaries. Is this correct? More generally, what is the expected amount of source and build parameter skew in your production environment? Are you dealing with occasional cherrypicks, or your production releases have longer lapses which introduce much larger source and profile skews?

A simple way of introducing source drift is to collect the profile from a binary built at an older githash. A more advanced and meaningful skew experiment involves changing hot functions and making sure that the profile is properly recovered. Overall, if source drift is an important goal, additional data points will make the RFC much stronger and aligned with the scope.

We conducted experiments where Clang was used to compile Clang, aiming to verify the impact of expired profiles at different time points on Propeller’s optimization performance. The results, illustrated in the figure below.

For the original Propeller, the optimization efficacy deteriorates rapidly over time. Specifically, when employing a profile from a year ago, it essentially offers no optimization benefits. In stark contrast, the Propeller enhanced with the matching and inference functionality demonstrates significantly greater resilience. Its optimization performance decays much more gradually, maintaining approximately 8% effectiveness even when utilizing a profile that is a year old.

These findings strongly validate that integrating the matching and inference features substantially improves Propeller’s tolerance to expired profiles, ensuring more consistent optimization performance despite the age of the profiles.