linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Joe Perches' <joe@perches.com>, Arnd Bergmann <arnd@arndb.de>,
	"Oleksandr Natalenko" <oleksandr@redhat.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: RE: [PATCH] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for gcc >= 10
Date: Sun, 10 May 2020 12:47:13 +0000	[thread overview]
Message-ID: <9590a4674863448e8b13fee5086fcf73@AcuMS.aculab.com> (raw)
In-Reply-To: <c774d7371a9599526090e63e85f61e69bddf4795.camel@perches.com>

From: Joe Perches
> Sent: 08 May 2020 16:06
> On Fri, 2020-05-08 at 13:49 +0200, Arnd Bergmann wrote:
> > Personally, I'm more interested in improving compile speed of the kernel
> 
> Any opinion on precompiled header support?

When ever I've been anywhere near it it is always a disaster.
It may make sense for C++ where there is lots of complicated
code to parse in .h files. Parsing C headers is usually easier.

One this I have done that significantly speeds up .h file
processing is to take the long list of '-I directory' parameters
that are passed to the compiler and copy the first version
of each file into a separate 'object headers' directory.
This saves the compiler doing lots of 'failed opens'.

If each fragment makefile lists its 'public' headers make
can generate dependency rules that do the copies.

FWIW make is much faster if you delete all the builtin and
suffix rules and rely on explicit rules for each file.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  parent reply	other threads:[~2020-05-10 12:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07 22:45 Jason A. Donenfeld
2020-05-08  8:35 ` Peter Zijlstra
2020-05-08  9:02 ` Oleksandr Natalenko
2020-05-08 11:21   ` Jason A. Donenfeld
2020-05-08 11:33     ` Oleksandr Natalenko
2020-05-08 11:49       ` Arnd Bergmann
2020-05-08 12:07         ` Jason A. Donenfeld
2020-05-08 13:04           ` Arnd Bergmann
2020-05-08 15:06         ` Joe Perches
2020-05-08 15:09           ` Arnd Bergmann
2020-05-10 12:47           ` David Laight [this message]
2020-05-10 17:45             ` Joe Perches
2020-05-10 18:58               ` David Laight
2020-05-12  1:10             ` Masahiro Yamada
2020-05-11 21:57   ` [PATCH v2] " Jason A. Donenfeld
2020-05-12  0:04     ` Linus Torvalds
2020-05-12  0:09       ` Linus Torvalds
2020-05-12  0:43       ` Jason A. Donenfeld
2020-05-12  8:44       ` Richard Biener
2020-05-13 11:27 ` [PATCH] " Artem S. Tashkinov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9590a4674863448e8b13fee5086fcf73@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=Jason@zx2c4.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleksandr@redhat.com \
    --cc=x86@kernel.org \
    --subject='RE: [PATCH] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for gcc >= 10' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).