From: Ingo Molnar <mingo@kernel.org>
To: Michael Matz <matz@suse.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Christopher Li <sparse@chrisli.org>,
virtualization@lists.linux-foundation.org,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Nadav Amit <namit@vmware.com>, Jan Beulich <JBeulich@suse.com>,
"H. Peter Anvin" <hpa@zytor.com>, Sam Ravnborg <sam@ravnborg.org>,
Thomas Gleixner <tglx@linutronix.de>,
x86@kernel.org, linux-sparse@vger.kernel.org,
Ingo Molnar <mingo@redhat.com>,
linux-xtensa@linux-xtensa.org, Kees Cook <keescook@chromium.org>,
Segher Boessenkool <segher@kernel.crashing.org>,
Chris Zankel <chris@zankel.net>, Borislav Petkov <bp@alien8.de>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Alok Kataria <akataria@vmware.com>,
Juergen Gross <jgross@suse.com>,
gcc@gcc.gnu.org, Richard Biener <rguenther@suse.de>,
Max Filippov <jcmvbkbc@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: PROPOSAL: Extend inline asm syntax with size spec
Date: Mon, 8 Oct 2018 08:13:23 +0200 [thread overview]
Message-ID: <20181008061323.GB66819@gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.21.1810071534220.7867@wotan.suse.de>
* Michael Matz <matz@suse.de> wrote:
> (without an built-in assembler which hopefully noone proposes).
There are disadvantages (the main one is having to implement it), but a built-in assembler has
numerous advantages as well:
- Better optimizations: for example -Os could more accurately estimate true instruction size.
- Better inlining: as the examples in this thread are showing.
- Better padding/alignment: right now GCC has no notion about the precise cache layout of the
assembly code it generates and the code alignment options it has are crude. It got away with
this so far because the x86 rule of thumb is that dense code is usually the right choice.
- Better compiler performance: it would be faster as well to immediately emit assembly
instructions, just like GCC's preprocessor library use speeds up compilation *significantly*
instead of creating a separate preprocessor task.
- Better future integration of assembly blocks: GCC could begin to actually understand the
assembly statements in inline asm and allow more user-friendly extensions to its
historically complex and difficult to master inline asm syntax.
I mean, it's a fact that the GNU project has *already* defined their own assembly syntax which
departs from decades old platform assembly syntax - and how the assembler is called by the
compiler is basically an implementation detail, not a conceptual choice. The random
multi-process unidirectional assembler choice of the past should not be treated as orthodoxy.
Thanks,
Ingo
next prev parent reply other threads:[~2018-10-08 6:13 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-03 21:30 [PATCH v9 00/10] x86: macrofying inline asm Nadav Amit
2018-10-03 21:30 ` [PATCH v9 02/10] Makefile: Prepare for using macros for " Nadav Amit
2018-11-06 18:57 ` Logan Gunthorpe
2018-11-06 19:18 ` Nadav Amit
2018-11-06 20:01 ` Logan Gunthorpe
2018-11-07 18:01 ` Nadav Amit
2018-11-07 18:53 ` Logan Gunthorpe
2018-11-07 18:56 ` Nadav Amit
2018-11-07 21:43 ` Logan Gunthorpe
2018-11-07 21:50 ` hpa
2018-11-08 6:18 ` Nadav Amit
2018-11-08 17:14 ` Logan Gunthorpe
2018-11-08 19:54 ` Nadav Amit
2018-11-08 20:00 ` Logan Gunthorpe
2018-11-08 20:18 ` Nadav Amit
2018-11-10 22:04 ` Nadav Amit
2018-11-13 4:56 ` Logan Gunthorpe
2018-10-03 21:30 ` [PATCH v9 03/10] x86: objtool: use asm macro for better compiler decisions Nadav Amit
2018-10-07 9:18 ` PROPOSAL: Extend inline asm syntax with size spec Borislav Petkov
2018-10-07 9:18 ` Borislav Petkov
2018-10-07 13:22 ` Segher Boessenkool
2018-10-07 14:13 ` Borislav Petkov
2018-10-07 15:14 ` Segher Boessenkool
2018-10-08 5:58 ` Ingo Molnar
2018-10-08 7:53 ` Segher Boessenkool
2018-10-08 5:58 ` Ingo Molnar
2018-10-07 14:13 ` Borislav Petkov
2018-10-07 15:53 ` Michael Matz
2018-10-08 6:13 ` Ingo Molnar [this message]
2018-10-08 8:18 ` Segher Boessenkool
2018-10-08 7:31 ` Segher Boessenkool
2018-10-08 9:07 ` Richard Biener
2018-10-08 10:02 ` Segher Boessenkool
2018-10-09 14:53 ` Segher Boessenkool
2018-10-10 6:35 ` Ingo Molnar
2018-10-10 7:12 ` Richard Biener
2018-10-10 7:22 ` Ingo Molnar
2018-10-10 8:03 ` Segher Boessenkool
2018-10-10 8:19 ` Borislav Petkov
2018-10-10 8:19 ` Borislav Petkov
2018-10-10 8:35 ` Richard Biener
2018-10-10 18:54 ` Segher Boessenkool
2018-10-10 19:14 ` Borislav Petkov
2018-10-13 19:33 ` Borislav Petkov
2018-10-13 21:14 ` Alexander Monakov
2018-10-13 21:30 ` Borislav Petkov
2018-10-25 10:24 ` Borislav Petkov
2018-10-25 10:24 ` Borislav Petkov
2018-10-31 12:55 ` Peter Zijlstra
2018-10-31 13:11 ` Peter Zijlstra
2018-10-31 16:31 ` Segher Boessenkool
2018-11-01 5:20 ` Joe Perches
2018-11-01 9:01 ` Peter Zijlstra
2018-11-01 9:20 ` Joe Perches
2018-11-01 11:15 ` Peter Zijlstra
2018-11-01 9:20 ` Joe Perches
2018-11-01 5:20 ` Joe Perches
2018-12-27 4:47 ` Masahiro Yamada
2018-10-10 19:14 ` Borislav Petkov
2018-10-10 10:29 ` Richard Biener
2018-10-10 7:53 ` Segher Boessenkool
2018-10-10 16:31 ` Nadav Amit
2018-10-10 19:21 ` Segher Boessenkool
2018-10-11 7:04 ` Richard Biener
2018-11-29 11:46 ` Masahiro Yamada
2018-11-29 11:46 ` Masahiro Yamada
2018-11-29 12:25 ` Segher Boessenkool
2018-11-30 9:06 ` Boris Petkov
2018-11-30 13:16 ` Segher Boessenkool
2018-12-10 8:16 ` Masahiro Yamada
2018-12-10 8:16 ` Masahiro Yamada
2018-11-30 9:06 ` Boris Petkov via Virtualization
2018-11-29 13:07 ` Borislav Petkov via Virtualization
2018-11-29 13:09 ` Richard Biener
2018-11-29 13:16 ` Borislav Petkov via Virtualization
2018-11-29 13:16 ` Borislav Petkov
2018-11-29 13:24 ` Richard Biener
2018-10-08 16:24 ` David Laight
2018-10-08 16:24 ` David Laight
2018-10-07 16:09 ` Nadav Amit
2018-10-07 16:13 ` [RESEND] " Nadav Amit
2018-10-07 16:46 ` Richard Biener
2018-10-07 19:06 ` Nadav Amit
2018-10-07 19:52 ` Jeff Law
2018-10-08 7:46 ` Richard Biener
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=20181008061323.GB66819@gmail.com \
--to=mingo@kernel.org \
--cc=JBeulich@suse.com \
--cc=akataria@vmware.com \
--cc=bp@alien8.de \
--cc=chris@zankel.net \
--cc=gcc@gcc.gnu.org \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jcmvbkbc@gmail.com \
--cc=jgross@suse.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=kstewart@linuxfoundation.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=matz@suse.de \
--cc=mingo@redhat.com \
--cc=namit@vmware.com \
--cc=peterz@infradead.org \
--cc=rguenther@suse.de \
--cc=sam@ravnborg.org \
--cc=segher@kernel.crashing.org \
--cc=sparse@chrisli.org \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux-foundation.org \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.