linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: Richard Henderson <rth@twiddle.net>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Why Plan 9 C compilers don't have asm("")
Date: Sun, 22 Jul 2001 00:44:57 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.33.0107220025500.6342-100000@penguin.transmeta.com> (raw)
In-Reply-To: <20010721234952.A4349@twiddle.net>


On Sat, 21 Jul 2001, Richard Henderson wrote:
>
> The call-clobbered GP means that your trampoline has to play games
> in order to get the GP restored when coming back from an intra
> module call.  Which means a new stack frame.

Ahh, only if you do my optimization of sharing trampolines among users.
And you're right, that won't work.

But if you don't do that, you don't need a stack frame. You just reload GP
and jump back to the caller.

And assuming most calls don't need the trampoline (and hey, they really
shouldn't), you're still way ahead. The only thing you lost was the icache
win of re-using the trampoline (and a few cycles for scheduling and the
extra short branch).

Think of it as nothing more than a branch prediction thing - you predict
that you can take a short branch, and emit the long-branch code
out-of-line.

So the code would be roughly (this is not how the compiler would see it,
this is the very last stage of outputting the actual assembly. Nothing
else needs to know):

	...
	bsr $26,trampoline	// linker overflow case
retpoint:
	....

trampoline:
	ldq $27,fn($gp)		// load the full address
	jsr $26,($27)		// branch to it
	ldgp $29,($26)		// reload our GP
	jsr $31,retpoint	// and go back to where we came from.

And the linker can just use the special .rel20 thing to turn the bsr into
a direct call when it can.

Overhead when it cannot: one extra "bsr", one extra "jsr" back, and the
lack of scheduling. You lost two cycles and maybe a pipeline stall or
something (branching around is never nice, even if it's unconditional).

But you only lose this on misprects. And you can have a pretty high
prediction accuracy, even with just static knowledge.

And when you _do_ predict right, you're going to win in icache footprint,
code size (and because you can drop the trampoline for non-weak symbolds
the executable size also goes down) and cycles.

That still doesn't look complicated to me. Of course, it clearly does
depend on whether I'm right that you can fairly easily get 99% prediction
accuracy. And I could just be full of sh*t.

		Linus


  reply	other threads:[~2001-07-22  7:46 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-04  3:37 Why Plan 9 C compilers don't have asm("") Rick Hohensee
2001-07-04  3:36 ` Olivier Galibert
2001-07-04  6:24   ` Cort Dougan
2001-07-04  8:03     ` H. Peter Anvin
2001-07-04 17:22     ` Linus Torvalds
2001-07-06  8:38       ` Cort Dougan
2001-07-06 18:44         ` Linus Torvalds
2001-07-06 20:02           ` Cort Dougan
2001-07-08 21:55           ` Victor Yodaiken
2001-07-08 22:28             ` Alan Cox
2001-07-09  1:22             ` Johan Kullstam
2001-07-08 22:29           ` David S. Miller
2001-07-06 11:43       ` David S. Miller
2001-07-21 22:10       ` Richard Henderson
2001-07-22  3:43         ` Linus Torvalds
2001-07-22  3:59           ` Mike Castle
2001-07-22  6:49           ` Richard Henderson
2001-07-22  7:44             ` Linus Torvalds [this message]
2001-07-22 15:53               ` Richard Henderson
2001-07-22 19:08                 ` Linus Torvalds
2001-07-04  7:15 ` pazke
2001-07-04 17:32 ` Don't feed the trooll [offtopic] " Ben LaHaise
2001-07-05  1:02 ` Michael Meissner
2001-07-05  1:54   ` Rick Hohensee
2001-07-05 16:54     ` Michael Meissner
2001-07-04 10:10 Rick Hohensee
2001-07-05  3:26 Rick Hohensee
2001-07-06 17:24 Rick Hohensee
2001-07-06 23:54 ` David S. Miller
2001-07-07  0:16   ` H. Peter Anvin
2001-07-07  0:37   ` David S. Miller
2001-07-07  6:16 Rick Hohensee
     [not found] <mailman.994629840.17424.linux-kernel2news@redhat.com>
2001-07-09  0:08 ` Pete Zaitcev
2001-07-09  0:28   ` Victor Yodaiken
2001-07-09  3:03 Rick Hohensee
2001-07-23  4:39 Rick Hohensee

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=Pine.LNX.4.33.0107220025500.6342-100000@penguin.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rth@twiddle.net \
    /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 NNTP newsgroup(s).