[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKwvOdn7bUOeiE8LobyENmPvYGO3j7rt1N+Ht7tcDWaOBuHhdg@mail.gmail.com>
Date: Thu, 9 May 2019 09:47:32 -0700
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Masahiro Yamada <yamada.masahiro@...ionext.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
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
Powered by blists - more mailing lists