[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK7LNARJiQcBSSkdyr6HKQd_v4uWD-2D1S9nhrponaYzivOABg@mail.gmail.com>
Date: Mon, 13 May 2019 11:23:51 +0900
From: Masahiro Yamada <yamada.masahiro@...ionext.com>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Sedat Dilek <sedat.dilek@...il.com>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Nathan Chancellor <natechancellor@...il.com>,
Arnd Bergmann <arnd@...db.de>,
Clang-Built-Linux ML <clang-built-linux@...glegroups.com>,
Michal Marek <michal.lkml@...kovi.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
chromeos-toolchain <chromeos-toolchain@...gle.com>,
Android-LLVM <android-llvm@...gle.com>
Subject: Re: [PATCH] kbuild: add some extra warning flags unconditionally
On Fri, May 10, 2019 at 1:47 AM Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
>
> From: Masahiro Yamada <yamada.masahiro@...ionext.com>
> > On Thu, May 9, 2019 at 4:11 PM Sedat Dilek <sedat.dilek@...il.com> wrote:
> > > BTW, is this a speedup when doing CC/LD FLAGS etc checks unconditionally?
> >
> > Yes.
> > cc-option is somewhat costly because it invoked the compiler to
> > check if the given flag is supported.
> >
> > So, I want to get rid of as many cc-option calls as possible.
> >
> >
> > > Asking in general - do you have any numbers :-)?
> >
> > Removing a couple of cc-options does not make
> > a measurable difference in general use-cases.
> >
> > But, this might be more beneficial for chrome OS
> > because $(CC) is a wrapper and invoking it is much more expensive.
>
> Android does too, which we plan on removing as we recently measured
> the performance cost of 5% for having a Python wrapper to aid in
> bisection.
>
> Anyways, I checked these options with clang 4 and gcc 4.6.4 in godbolt.
> Tested-by: Nick Desaulniers <ndesaulniers@...gle.com>
> --
> Thanks,
> ~Nick Desaulniers
Applied to linux-kbuild.
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists