LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
dsterba@suse.cz, Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] proc: use #pragma once
Date: Fri, 4 May 2018 01:23:12 +0200 [thread overview]
Message-ID: <94db646a-4fd8-9ce3-2111-b2e4852ad324@rasmusvillemoes.dk> (raw)
In-Reply-To: <20180503224257.GE30522@ZenIV.linux.org.uk>
On 2018-05-04 00:42, Al Viro wrote:
> On Fri, May 04, 2018 at 12:14:57AM +0200, Rasmus Villemoes wrote:
>
>> FWIW, it's not just removing some identifiers from cpp's hash tables, it
>> also reduces I/O: Due to our header mess, we have some cyclic includes,
>> e.g mm.h -> memremap.h -> mm.h. While parsing mm.h, cpp sees the #define
>> _LINUX_MM_H, then goes parsing memremap.h, but since it hasn't reached
>> the end of mm.h yet (seeing that there's nothing but comments outside
>> the #ifndef/#endif pair), it hasn't had a chance to set the internal
>> flag for mm.h, so it goes slurping in mm.h again. Obviously, the
>> definedness of _LINUX_MM_H at that point means it "only" has to parse
>> those 87K for comments and matching up #ifs, #ifdefs,#endifs etc. With
>> #pragma once, the flag gets set for mm.h immediately, so the #include
>> from memremap.h is entirely ignored. This can easily be verified with
>> strace. And mm.h is not the only header getting read twice.
>
> Which gcc version it is?
When I stumbled on this a few years ago (I was stracing gcc for some
reason), 4.something. Verifying today, 5.4.
> Does it *really* read anything twice?
Yes, just do "strace -f" and grep 'open.*= [0-9]'.
> After all, you are going to read (and tokenize) the rest of mm.h anyway, so if it
> throws away the file it has read, only to reread it again, it's bloody
> dumb.
Hm, yes, gcc should be able to hang the buffer off of the structure it
keeps around anyway for tracking the status of mm.h. But it doesn't.
> Note that sequence of preprocessor tokens does not depend upon the ifdefs;
> anything under #if 0 *is* tokenized all the same. So it's not even that
> "parsing" (tokenizing, actually) has to be repeated.
Are you sure about that? Maybe formally it has to (if the phases are
done strictly sequentially), but can't it go into some fast-forward mode
under #if 0 (or #ifndef $some-defined-macro) where it only looks for
string and char literals, comments and "control-flow" directives?
libcpp/internal.h does have
/* True if we are skipping a failed conditional group. */
unsigned char skipping;
Rasmus
next prev parent reply other threads:[~2018-05-03 23:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-23 21:35 Alexey Dobriyan
2018-04-24 13:54 ` Christoph Hellwig
2018-04-25 20:55 ` Alexey Dobriyan
2018-04-26 10:26 ` David Sterba
2018-04-26 10:33 ` Christoph Hellwig
2018-04-26 19:25 ` Alexey Dobriyan
2018-04-26 19:24 ` Alexey Dobriyan
2018-05-01 22:13 ` Andrew Morton
2018-05-03 22:14 ` Rasmus Villemoes
2018-05-03 22:42 ` Al Viro
2018-05-03 23:23 ` Rasmus Villemoes [this message]
2018-05-04 2:58 ` Al Viro
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=94db646a-4fd8-9ce3-2111-b2e4852ad324@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dsterba@suse.cz \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
--subject='Re: [PATCH] proc: use #pragma once' \
/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).