From: Andy Lutomirski <luto@amacapital.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jason Baron <jbaron@akamai.com>,
Steven Rostedt <rostedt@goodmis.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC][PATCH 3/2] x86/jump labels: Count and display the short jumps used
Date: Fri, 09 Aug 2013 17:14:23 -0700 [thread overview]
Message-ID: <520585DF.6010002@mit.edu> (raw)
In-Reply-To: <CA+55aFykSZb-XmGU0WjZDuiSUXQ6RbRhV3ZH5BUFCRifaoLUGA@mail.gmail.com>
On 08/07/2013 02:56 PM, Linus Torvalds wrote:
>
> Both of the biased cases *might* also want things like "save register
> state in the unlikely path so that the *likely* path doesn't have to".
> Think things like "it's a leaf function, and the likely path doesn't
> need any temporaries, but the unlikely path ends up doing function
> calls and needs a stack frame". If the compiler can make likely path
> avoid the stack frame generation and be straight-line, that would be
> really nice.
This inspired me to see what happens when you call an
__attribute__((noreturn)) function. The results are sad:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
I think the explanations for why that bug is WONTFIX are bogus. And
unless gcc fixes that, trying to get efficient code that intentionally
jumps and never returns seems hard (at least without sticking the
call/jump into inline assembly).
--Andy
prev parent reply other threads:[~2013-08-10 0:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-07 17:36 [RFC][PATCH 0/2] x86/jump labels: Add the 5 byte or 2 byte jumps Steven Rostedt
2013-08-07 17:36 ` [RFC][PATCH 1/2] jump labels: Add infrastructure to update jump labels at compile time Steven Rostedt
2013-08-07 17:36 ` [RFC][PATCH 2/2] x86/jump labels: Use etiher 5 byte or 2 byte jumps Steven Rostedt
2013-08-07 17:57 ` Steven Rostedt
2013-08-07 17:54 ` [RFC][PATCH 3/2] x86/jump labels: Count and display the short jumps used Steven Rostedt
2013-08-07 19:22 ` Linus Torvalds
2013-08-07 19:27 ` H. Peter Anvin
2013-08-07 19:49 ` Linus Torvalds
2013-08-07 20:30 ` Steven Rostedt
2013-08-07 20:19 ` Jason Baron
2013-08-07 20:33 ` Steven Rostedt
2013-08-07 20:47 ` Linus Torvalds
2013-08-07 21:37 ` Jason Baron
2013-08-07 21:56 ` Linus Torvalds
2013-08-10 0:14 ` Andy Lutomirski [this message]
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=520585DF.6010002@mit.edu \
--to=luto@amacapital.net \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=jbaron@akamai.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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