On Fri, 24 Sep 2021 23:20:40 +0300 Dmitry V. Levin wrote:
> On Fri, Sep 24, 2021 at 10:48:06PM +0300, Andrey Savchenko wrote:
> > On Fri, 24 Sep 2021 21:29:36 +0300 Dmitry V. Levin wrote:
> > > On Fri, Sep 24, 2021 at 08:04:59PM +0300, Andrey Savchenko wrote:
> > > > On Fri, 24 Sep 2021 18:18:04 +0300 Dmitry V. Levin wrote:
> > > > > On Fri, Sep 24, 2021 at 08:48:12AM +0300, Anton Farygin wrote:
> > > > > > Да, Илья.
> > > > > > 
> > > > > > Есть ещё вот такая статья годичной давности:
> > > > > > https://johnysswlab.com/link-time-optimizations-new-way-to-do-compiler-optimizations/
> > > > > > 
> > > > > > и там интересная заметка про ffmpeg, в которой говорится о том, что 
> > > > > > выигрыш в сборке с LTO может быть нулевым.
> > > > > 
> > > > > Особенно если в случае LTO ещё и выключить в пакете часть ассемблерных
> > > > > оптимизаций.
> > > > 
> > > > Если ты внимательно читал статью, то там и в тесте без LTO они
> > > > оставались выключенными. А вообще, тот факт, что ради LTO
> > > > приходится отключать сильные оптимизации
> > > 
> > > Не надо ради LTO отключать сильные оптимизации.
> > > Странно, что в ffmpeg так сделали.
> > 
> > Пожалуйста, прочитай внимательно исходную ссылку. Не разработчики
> > ffmpeg так сделали, а автор теста выключил asm, чтоб можно было
> > сравнить ffmpeg с lto и без lto в чистом виде.
> 
> Я про то, что именно разработчики ffmpeg для включения LTO почему-то
> выключают часть ассемблерной оптимизации.

Потому что gcc неспособен скомпилировать все ассемблерные
оптимизации вместе с LTO. Но, как мы уже выяснили, разработчиков
gcc это не особо волнует.

Best regards,
Andrew Savchenko