From: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
To: Jeff Sturm <jsturm@one-point.com>
Cc: tromey@redhat.com, Dan Nicolaescu <dann@godzilla.ics.uci.edu>,
java@gcc.gnu.org, gcc@gcc.gnu.org
Subject: Re: java aliasing rules
Date: Sat, 30 Mar 2002 15:04:00 -0000 [thread overview]
Message-ID: <3CA64458.7030105@waitaki.otago.ac.nz> (raw)
In-Reply-To: <Pine.LNX.4.10.10203300926250.5677-100000@mars.deadcafe.org>
Jeff Sturm wrote:
>>The optimal, correct code for
>>Java is really something like:
>>
>>lhz r9, [ps1.f1]
>>addi r9,r9,1
>>sth r9, [ps1.f1]
>>
>
>Wouldn't accessing r9 immediately after the load cause a pipeline stall?
>Assuming an in-order processor? That would be a significant performance
>hit.
>
Right, its not optimal scheduling, but there's no way to avoid that and
still have the correct behaviour for NullPointers. And as you suggest, a
modern processor may be speculativly executing the following loads, so
it probibly doesn't matter too much.
>Come to think of it, what happens on an out-of-order processor (e.g.
>Alpha EV6) when an instruction traps? Are preceding instructions
>guaranteed to have completed? I'm curious.
>
No matter what re-ordering the hardware does internally, everything must
be seen to be executed sequentially. So if an instruction traps while
being executed out of order, any following instructions (eg in the
signal handler) that depend on results of instructions before the trap,
must see the results of them having been run.
regards
Bryce.
next prev parent reply other threads:[~2002-03-30 23:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-27 11:43 Dan Nicolaescu
2002-03-27 13:53 ` Tom Tromey
2002-03-27 16:03 ` Dan Nicolaescu
2002-03-27 16:47 ` Tom Tromey
2002-03-27 20:00 ` Dan Nicolaescu
2002-03-27 15:54 ` Bryce McKinlay
2002-03-27 16:45 ` Tom Tromey
2002-03-28 22:02 ` Bryce McKinlay
2002-03-28 22:13 ` Richard Henderson
2002-03-28 22:15 ` Tom Tromey
2002-03-29 15:22 ` Bryce McKinlay
2002-03-29 16:26 ` Richard Henderson
2002-03-30 6:37 ` Jeff Sturm
2002-03-30 13:55 ` Richard Henderson
2002-03-30 15:04 ` Bryce McKinlay [this message]
2002-04-04 10:57 ` Jeff Sturm
2002-04-04 12:57 ` Andrew Haley
2002-04-04 14:20 ` Jeff Sturm
2002-04-04 17:04 ` Bryce McKinlay
2002-04-04 20:39 ` Jeff Sturm
2002-04-05 1:07 ` Bryce McKinlay
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=3CA64458.7030105@waitaki.otago.ac.nz \
--to=bryce@waitaki.otago.ac.nz \
--cc=dann@godzilla.ics.uci.edu \
--cc=gcc@gcc.gnu.org \
--cc=java@gcc.gnu.org \
--cc=jsturm@one-point.com \
--cc=tromey@redhat.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).