From: Segher Boessenkool <segher@kernel.crashing.org>
To: Borislav Petkov <bp@alien8.de>
Cc: gcc@gcc.gnu.org, Richard Biener <rguenther@suse.de>,
Michael Matz <matz@suse.de>, Nadav Amit <namit@vmware.com>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Sam Ravnborg <sam@ravnborg.org>,
Alok Kataria <akataria@vmware.com>,
Christopher Li <sparse@chrisli.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"H. Peter Anvin" <hpa@zytor.com>, Jan Beulich <JBeulich@suse.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Juergen Gross <jgross@suse.com>,
Kate Stewart <kstewart@linuxfoundation.org>,
Kees Cook <keescook@chromium.org>,
linux-sparse@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Philippe Ombredanne <pombredan ne@nexb.com>,
Thomas Gleixner <tglx@linutronix.de>,
virtualization@lists.linux-found
Subject: Re: PROPOSAL: Extend inline asm syntax with size spec
Date: Sun, 7 Oct 2018 08:22:28 -0500 [thread overview]
Message-ID: <20181007132228.GJ29268@gate.crashing.org> (raw)
In-Reply-To: <20181007091805.GA30687@zn.tnic>
On Sun, Oct 07, 2018 at 11:18:06AM +0200, Borislav Petkov wrote:
> this is an attempt to see whether gcc's inline asm heuristic when
> estimating inline asm statements' cost for better inlining can be
> improved.
GCC already estimates the *size* of inline asm, and this is required
*for correctness*. So any workaround that works against this will only
end in tears.
Taking size as an estimate of cost is not very good. But in your
motivating example you actually *do* care mostly about size, namely, for
the inlining decisions.
So I guess the real issue is that the inline asm size estimate for x86
isn't very good (since it has to be pessimistic, and x86 insns can be
huge)?
> Now, Richard suggested doing something like:
>
> 1) inline asm ("...")
What would the semantics of this be?
> 2) asm ("..." : : : : <size-expr>)
This potentially conflicts with the syntax for asm goto.
> 3) asm ("...") __attribute__((asm_size(<size-expr>)));
Eww.
> with which user can tell gcc what the size of that inline asm statement
> is and thus allow for more precise cost estimation and in the end better
> inlining.
More precise *size* estimates, yes. And if the user lies he should not
be surprised to get assembler errors, etc.
> And FWIW 3) looks pretty straight-forward to me because attributes are
> pretty common anyways.
I don't like 2) either. But 1) looks interesting, depends what its
semantics would be? "Don't count this insn's size for inlining decisions",
maybe?
Another option is to just force inlining for those few functions where
GCC currently makes an inlining decision you don't like. Or are there
more than a few?
Segher
next prev parent reply other threads:[~2018-10-07 13:22 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 [this message]
2018-10-07 14:13 ` Borislav Petkov
2018-10-07 15:14 ` Segher Boessenkool
2018-10-08 5:58 ` Ingo Molnar
2018-10-08 5:58 ` Ingo Molnar
2018-10-08 7:53 ` Segher Boessenkool
2018-10-07 14:13 ` Borislav Petkov
2018-10-07 15:53 ` Michael Matz
2018-10-08 6:13 ` Ingo Molnar
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 via Virtualization
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-29 13:07 ` Borislav Petkov via Virtualization
2018-11-29 13:09 ` Richard Biener
2018-11-29 13:16 ` Borislav Petkov
2018-11-29 13:24 ` Richard Biener
2018-11-29 13:16 ` Borislav Petkov via Virtualization
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=20181007132228.GJ29268@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=JBeulich@suse.com \
--cc=akataria@vmware.com \
--cc=bp@alien8.de \
--cc=gcc@gcc.gnu.org \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=kstewart@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.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=sparse@chrisli.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.