lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0dJ0vNnktcoWFiPKB4NJbeyf7nvwWf0YLyeUyxT5pvQg@mail.gmail.com>
Date:   Fri, 8 May 2020 13:49:44 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Oleksandr Natalenko <oleksandr@...hat.com>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for
 gcc >= 10

On Fri, May 8, 2020 at 1:33 PM Oleksandr Natalenko <oleksandr@...hat.com> wrote:
>
> On Fri, May 08, 2020 at 05:21:47AM -0600, Jason A. Donenfeld wrote:
> > > Should we untangle -O3 from depending on ARC first maybe?
> >
> > Oh, hah, good point. Yes, I'll do that for a v2, but will wait another
> > day for feedback first.
>
> Just keep in mind that my previous attempt [1] failed because of too
> many false positive warnings despite -O3 really uncovered a couple of
> bugs in the codebase.

I think my warning fixes were mostly picked up in the meantime, but
if there are any remaining, they would be mixed in with random other
fixes in my testing tree, so it's hard to know for sure.

I also want to hear the feedback from the gcc developers about what
the general recommendations are between O2 and O3, and how
they may have changed over time. According to the gcc-10 documentation,
the difference between -O2 and -O3 is exactly this set of options:

-fgcse-after-reload
-fipa-cp-clone
-floop-interchange
-floop-unroll-and-jam
-fpeel-loops
-fpredictive-commoning
-fsplit-loops
-fsplit-paths
-ftree-loop-distribution
-ftree-loop-vectorize
-ftree-partial-pre
-ftree-slp-vectorize
-funswitch-loops
-fvect-cost-model
-fvect-cost-model=dynamic
-fversion-loops-for-strides

It's a relatively short list, so someone familiar with the options could
perhaps look into whether we want to change the default for all
of them, or if it makes sense to be more selective.

Personally, I'm more interested in improving compile speed of the kernel
and eventually supporting -Og or some variant of it for my own build
testing, but of course I also want to make sure that the other optimization
levels do not produce warnings, and -Og leads to more problems than
-O3 at the moment.

       Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ