| Message ID | 20220621133526.29662-1-mikoxyzzz@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Kconfig: -O3 enablement | expand |
On Tue, Jun 21, 2022 at 6:35 AM Miko Larsson <mikoxyzzz@gmail.com> wrote: > > Hi, > > This very small series allows -O3 to be used for all architectures. The > first patch marks -O3 as experimental, with the reasoning being that it > might expose unwanted regressions to users, and the second patch > actually allows -O3 by removing the "depend on ARC" string. I think we should just remove -O3 support from KCONFIG. If someone wants to mess around with "experimental features," there's nothing stopping you from doing: $ make KCFLAGS=-O3 > > The reasoning behind this series is to open up -O3 so that bugs related > to it (both compiler-related and kernel-related) can be discovered by > eyeballs wanting to improve the "-O3 experience," as that might be > beneficial to both compilers and the kernel. This has been attempted > before [1], but unfortunately nothing ever came of it. > > [1] https://lore.kernel.org/lkml/20191211104619.114557-1-oleksandr@redhat.com/ > > Cc: linux-kbuild@vger.kernel.org > Cc: x86@kernel.org > Cc: Nathan Chancellor <nathan@kernel.org> > Cc: Vlastimil Babka <vbabka@suse.cz> > Cc: Nick Desaulniers <ndesaulniers@google.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > Cc: Sean Christopherson <seanjc@google.com> > Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Chris Down <chris@chrisdown.name> > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> > Cc: John Ogness <john.ogness@linutronix.de> > Cc: Elliot Berman <quic_eberman@quicinc.com> > Cc: Oleksandr Natalenko <oleksandr@redhat.com> > > Miko Larsson (2): > Kconfig: Mark -O3 as experimental > Kconfig: Allow -O3 for all architectures > > init/Kconfig | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > -- > 2.36.1 >
On Wed, Jun 22, 2022 at 1:17 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > On Tue, Jun 21, 2022 at 6:35 AM Miko Larsson <mikoxyzzz@gmail.com> wrote: > > > > Hi, > > > > This very small series allows -O3 to be used for all architectures. The > > first patch marks -O3 as experimental, with the reasoning being that it > > might expose unwanted regressions to users, and the second patch > > actually allows -O3 by removing the "depend on ARC" string. > > I think we should just remove -O3 support from KCONFIG. > > If someone wants to mess around with "experimental features," there's > nothing stopping you from doing: > > $ make KCFLAGS=-O3 > ARC uses -O3 since day1. "Generic build system uses -O2, we want -O3" in commit cfdbc2e16e65c1ec1c23057640607cee98d1a1bd If they want -O3, it is up to the ARC maintainer. If you want to say "use this option carefully", EXPERT might be another option. depends on ARC || EXPERT > > > > The reasoning behind this series is to open up -O3 so that bugs related > > to it (both compiler-related and kernel-related) can be discovered by > > eyeballs wanting to improve the "-O3 experience," as that might be > > beneficial to both compilers and the kernel. This has been attempted > > before [1], but unfortunately nothing ever came of it. > > > > [1] https://lore.kernel.org/lkml/20191211104619.114557-1-oleksandr@redhat.com/ > > > > Cc: linux-kbuild@vger.kernel.org > > Cc: x86@kernel.org > > Cc: Nathan Chancellor <nathan@kernel.org> > > Cc: Vlastimil Babka <vbabka@suse.cz> > > Cc: Nick Desaulniers <ndesaulniers@google.com> > > Cc: Thomas Gleixner <tglx@linutronix.de> > > Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > > Cc: Sean Christopherson <seanjc@google.com> > > Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> > > Cc: Arnd Bergmann <arnd@arndb.de> > > Cc: Chris Down <chris@chrisdown.name> > > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> > > Cc: John Ogness <john.ogness@linutronix.de> > > Cc: Elliot Berman <quic_eberman@quicinc.com> > > Cc: Oleksandr Natalenko <oleksandr@redhat.com> > > > > Miko Larsson (2): > > Kconfig: Mark -O3 as experimental > > Kconfig: Allow -O3 for all architectures > > > > init/Kconfig | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > -- > > 2.36.1 > > > > > -- > Thanks, > ~Nick Desaulniers
On Wednesday, 22 June 2022 03:57:34 CEST Masahiro Yamada wrote: > If you want to say "use this option carefully", > EXPERT might be another option. > > depends on ARC || EXPERT > Yeah, this would be a fair compromise, though I think it would be better to use "visible if" instead of "depends on". I can get a v2 of the series together if this is desired. -- ~miko
On Fri, Jun 24, 2022 at 12:42 AM Miko Larsson <mikoxyzzz@gmail.com> wrote: > > On Wednesday, 22 June 2022 03:57:34 CEST Masahiro Yamada wrote: > > If you want to say "use this option carefully", > > EXPERT might be another option. > > > > depends on ARC || EXPERT > > > > Yeah, this would be a fair compromise, though I think it would be > better to use "visible if" instead of "depends on". I can get a v2 of > the series together if this is desired. Why is "visible if" better than "depends on"? > -- > ~miko > > -- Best Regards Masahiro Yamada
On Thursday, 23 June 2022 17:44:57 CEST Masahiro Yamada wrote: > On Fri, Jun 24, 2022 at 12:42 AM Miko Larsson <mikoxyzzz@gmail.com> wrote: > > On Wednesday, 22 June 2022 03:57:34 CEST Masahiro Yamada wrote: > > > If you want to say "use this option carefully", > > > EXPERT might be another option. > > > > > > depends on ARC || EXPERT > > > > Yeah, this would be a fair compromise, though I think it would be > > better to use "visible if" instead of "depends on". I can get a v2 of > > the series together if this is desired. > > Why is "visible if" better than "depends on"? > Technically it most likely doesn't matter, but logically it makes more sense, since we'd make CC_OPTIMIZE_FOR_PERFORMANCE_O3 be visible if we're on ARC or if we have EXPERT enabled, instead of depending on them. But yeah, it probably doesn't matter. -- ~miko
On Fri, Jun 24, 2022 at 2:00 AM Miko Larsson <mikoxyzzz@gmail.com> wrote: > > On Thursday, 23 June 2022 17:44:57 CEST Masahiro Yamada wrote: > > On Fri, Jun 24, 2022 at 12:42 AM Miko Larsson <mikoxyzzz@gmail.com> wrote: > > > On Wednesday, 22 June 2022 03:57:34 CEST Masahiro Yamada wrote: > > > > If you want to say "use this option carefully", > > > > EXPERT might be another option. > > > > > > > > depends on ARC || EXPERT > > > > > > Yeah, this would be a fair compromise, though I think it would be > > > better to use "visible if" instead of "depends on". I can get a v2 of > > > the series together if this is desired. > > > > Why is "visible if" better than "depends on"? > > > > Technically it most likely doesn't matter, but logically it makes more > sense, since we'd make CC_OPTIMIZE_FOR_PERFORMANCE_O3 be visible if > we're on ARC or if we have EXPERT enabled, instead of depending on > them. But yeah, it probably doesn't matter. Did you write and test the code? "visible if" is only supported for "menu". This is clearly documented at line 207 of Documentation/kbuild/kconfig-language.rst Using "visible if" for config entry will just result in the syntax error. > -- > ~miko > > > -- Best Regards Masahiro Yamada
On Wed, Jun 22, 2022 at 3:57 AM Masahiro Yamada <masahiroy@kernel.org> wrote: > On Wed, Jun 22, 2022 at 1:17 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > > > On Tue, Jun 21, 2022 at 6:35 AM Miko Larsson <mikoxyzzz@gmail.com> wrote: > > > > > > Hi, > > > > > > This very small series allows -O3 to be used for all architectures. The > > > first patch marks -O3 as experimental, with the reasoning being that it > > > might expose unwanted regressions to users, and the second patch > > > actually allows -O3 by removing the "depend on ARC" string. > > > > I think we should just remove -O3 support from KCONFIG. I agree that would be best > > If someone wants to mess around with "experimental features," there's > > nothing stopping you from doing: > > > > $ make KCFLAGS=-O3 > > > > ARC uses -O3 since day1. > > "Generic build system uses -O2, we want -O3" > in commit cfdbc2e16e65c1ec1c23057640607cee98d1a1bd > > If they want -O3, it is up to the ARC maintainer. I suppose whatever the reason for using -O3 at the time has likely changed by now. > If you want to say "use this option carefully", > EXPERT might be another option. > > depends on ARC || EXPERT This probably also needs a dependency on !COMPILE_TEST so we don't report compile-time problems that are specific to -O3. Maybe a good first step would be to turn this into depends on ARCH && EXPERT && !COMPILE_TEST which should help both with compile-testing on ARC, and it would prevent it from being visible on other architectures. Arnd
On Thursday, 23 June 2022 19:15:14 CEST Masahiro Yamada wrote: > On Fri, Jun 24, 2022 at 2:00 AM Miko Larsson <mikoxyzzz@gmail.com> wrote: > > On Thursday, 23 June 2022 17:44:57 CEST Masahiro Yamada wrote: > > > On Fri, Jun 24, 2022 at 12:42 AM Miko Larsson <mikoxyzzz@gmail.com> wrote: > > > > On Wednesday, 22 June 2022 03:57:34 CEST Masahiro Yamada wrote: > > > > > If you want to say "use this option carefully", > > > > > EXPERT might be another option. > > > > > > > > > > depends on ARC || EXPERT > > > > > > > > Yeah, this would be a fair compromise, though I think it would be > > > > better to use "visible if" instead of "depends on". I can get a v2 of > > > > the series together if this is desired. > > > > > > Why is "visible if" better than "depends on"? > > > > Technically it most likely doesn't matter, but logically it makes more > > sense, since we'd make CC_OPTIMIZE_FOR_PERFORMANCE_O3 be visible if > > we're on ARC or if we have EXPERT enabled, instead of depending on > > them. But yeah, it probably doesn't matter. > > Did you write and test the code? > Admittedly, I didn't, since I had falsely assumed that "visible if" was just an "alternative" to "depends on". > "visible if" is only supported for "menu". > This is clearly documented at line 207 > of Documentation/kbuild/kconfig-language.rst > > > Using "visible if" for config entry will just > result in the syntax error. > Oops, yeah, I wasn't aware of this. Sorry. -- ~miko