This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC, PATCH] Disable -fprofile-use related optimizations if corresponding .gcda file not found.
- From: pinskia at gmail dot com
- To: Maxim Ostapenko <m dot ostapenko at partner dot samsung dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Vyacheslav Barinov <v dot barinov at samsung dot com>, Nikolay Bozhenov <n dot bozhenov at samsung dot com>, Slava Garbuzov <v dot garbuzov at samsung dot com>
- Date: Wed, 7 Oct 2015 10:07:12 -0700
- Subject: Re: [RFC, PATCH] Disable -fprofile-use related optimizations if corresponding .gcda file not found.
- Authentication-results: sourceware.org; auth=none
- References: <5615442E dot 9090200 at partner dot samsung dot com> <CA+=Sn1mDTn9JdqoqXngjCktWEHwtuku3zP3+odZ4FnJVBM_cPA at mail dot gmail dot com> <56154822 dot 9070703 at partner dot samsung dot com>
> On Oct 7, 2015, at 9:28 AM, Maxim Ostapenko <m.ostapenko@partner.samsung.com> wrote:
>
>
>
>> On 07/10/15 19:18, Andrew Pinski wrote:
>> On Wed, Oct 7, 2015 at 9:11 AM, Maxim Ostapenko
>> <m.ostapenko@partner.samsung.com> wrote:
>>> Hi,
>>>
>>> when testing OpenSSL performance, I found out that 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. However, even if profile data is not presented,
>>> GCC doesn't switch back -fprofile-use dependent optimizations (e.g.
>>> -fbranch-probabilities, -fvpt, etc). This may also lead to performance
>>> degradations.
>>>
>>> The issue had already raised quite time ago
>>> (https://gcc.gnu.org/ml/gcc-patches/2009-09/msg02119.html), but for some
>>> reasons wasn't discussed.
>>>
>>> Here a draft patch that disables -fprofile-use related optimizations if
>>> profile data wasn't found (perhaps it makes sense to introduce a special
>>> switch for this?). Does this look reasonable?
>> I thought if profile is not present, then branch probabilities goes
>> back to the original heuristics?
>> Which option is really causing the performance degradation here?
>
> -fprofile-use enabled -fpeel-loops that in turn enabled -frename-registers. This caused the scheduler to transform the code in sched2 pass.
Why not figure out how much to improve that instead. Rename register is just doing renaming of register usage and not undoing any scheduling at all (well it might cause some moves to be removed). I think you really should dig into deeper why it is causing a performance issue.
>
>> Also I think your patch is very incomplete as someone could use
>> -frename-registers with -fprofile-use and then you just turned it off.
>>
>> Thanks,
>> Andrew Pinski
>
> Doesn't -fprofile-use enable -frename-registers transitively through -fpeel-loops?
Yes. But I am saying some one could do -fprofile-use -frename-registers and expect rename registers to stay on even if there is no profile.
Thanks,
Andrew
>
>>> Thanks,
>>> -Maxim
>