On Tue, Oct 27, 2015 at 10:14 AM, Maxim Ostapenko <m.ostape...@partner.samsung.com> wrote: > Hi! > > As was pointed out in previous thread > (https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00723.html), sometimes > PGO-built binaries can actually introduce performance regressions. We could > identify affected object files and disable PGO for them by simply removing > corresponding .gcda file.
Did you analyze where the performance regressions came from? > My previous patch was incomplete and had two major drawbacks: > > * It disabled unrelated options (e.g. -frename-registers) and PGO-related > options, set up by user explicitly, if corresponding .gcda file is not > found. > * As Markus pointed out, in many cases we actually don't want to disable > PGO-related options even if .gcda file is missing. > > This patch tries to solve these issues in the following way: > > * Introduce new -fprofile-use-partial switch. > * If -fprofile-use-partial is ON, try to find corresponding .gcda file in > the very early stage during compiler invoking (actually, when common command > line options are parsed). If .gcda file exists, enable PGO-related > optimizations and emit warning otherwise. I believe this should not break > existing code. > > Regtested and bootstrapped on x86_64-unknown-linux-gnu. > > Does the patch look sensible? It still somehow feels like a hack. I think it should operate on a function granularity and the user should be able to specify a fallback to use (do we actually guess the profile if it fails to read? what if the profile is missing just for some functions, like if the gcda file is older than sources?). Which means that we should be able to somehow "late" disable some options from inside the IPA tree-profile pass. In principle we have DECL_FUNCTION_SPECIFIC_OPTIMIZATION nodes on each function so disabling of flags should be possible (but we've lost whether they were the default or user-controlled at that point). Honza, any further ideas here? Thanks, Richard. > Thanks, > -Maxim
