From: Will Deacon <will@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jakub Jelinek <jakub@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
linux-toolchains@vger.kernel.org, "Uecker,
Martin" <Martin.Uecker@med.uni-goettingen.de>,
"amonakov@ispras.ru" <amonakov@ispras.ru>,
"ubizjak@gmail.com" <ubizjak@gmail.com>,
"luto@kernel.org" <luto@kernel.org>
Subject: Re: Re: typeof and operands in named address spaces
Date: Tue, 17 Nov 2020 22:15:45 +0000 [thread overview]
Message-ID: <20201117221545.GA524@willie-the-truck> (raw)
In-Reply-To: <20201117211053.GA32727@willie-the-truck>
On Tue, Nov 17, 2020 at 09:10:53PM +0000, Will Deacon wrote:
> On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote:
> > On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek <jakub@redhat.com> wrote:
> > >
> > > It would need to be typeof( (typeof(type)) (type) ) to not be that
> > > constrained on what kind of expressions it accepts as arguments.
> >
> > Yup.
> >
> > > Anyway, it won't work with array types at least,
> > > int a[10];
> > > typeof ((typeof (a)) (a)) b;
> > > is an error (in both gcc and clang), while typeof (a) b; will work
> > > (but not drop the qualifiers). Don't know if the kernel cares or not.
> >
> > Well, the kernel already doesn't allow that, because our existing
> > horror only handles simple integer scalar types.
> >
> > So that macro is a clear improvement - if it actually works (local
> > testing says it does, but who knows about random compiler versions
> > etc)
>
> I'll give it a go now, although if it works I honestly won't know whether
> to laugh or cry.
GCC 9 and Clang 11 both seem to generate decent code for aarch64 defconfig
with:
#define __unqual_scalar_typeof(x) typeof( (typeof(x)) (x))
replacing the current monstrosity. allnoconfig and allmodconfig build fine
too.
However, GCC 4.9.0 goes mad and starts spilling to the stack when dealing
with a pointer to volatile, as though we were just using typeof(). I tried
GCC 5.4.0 and that looks ok, so I think if anybody cares about the potential
performance regression with 4.9 then perhaps they should consider upgrading
their toolchain.
In other words, let's do it.
Will
next prev parent reply other threads:[~2020-11-17 22:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-15 10:51 Uecker, Martin
2020-11-16 9:11 ` Richard Biener
2020-11-16 11:10 ` Peter Zijlstra
2020-11-16 11:23 ` Peter Zijlstra
2020-11-16 12:23 ` Uecker, Martin
2020-11-16 13:07 ` Peter Zijlstra
2020-11-17 19:13 ` Linus Torvalds
2020-11-17 19:25 ` Jakub Jelinek
2020-11-17 19:31 ` Linus Torvalds
2020-11-17 21:10 ` Will Deacon
2020-11-17 22:15 ` Will Deacon [this message]
2020-11-17 21:23 ` Uecker, Martin
2020-11-17 19:47 ` Linus Torvalds
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=20201117221545.GA524@willie-the-truck \
--to=will@kernel.org \
--cc=Martin.Uecker@med.uni-goettingen.de \
--cc=amonakov@ispras.ru \
--cc=gcc@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=linux-toolchains@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=ubizjak@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).