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: Thu, 04 Apr 2002 17:04:00 -0000 [thread overview]
Message-ID: <3CACF360.4070209@waitaki.otago.ac.nz> (raw)
In-Reply-To: <Pine.LNX.4.10.10204041316390.14501-100000@mars.deadcafe.org>
Jeff Sturm wrote:
>Am I correct in thinking this is only an issue for -fnon-call-exceptions?
>
>It might be useful to turn this "correctness" off with a compiler option,
>as we do with -fno-bounds-check. I habitually check for null in my code,
>and don't do anything useful with a NullPointerException besides aborting.
>I suspect that's true of a great deal of Java code.
>
Turning it off (although note that currently it isn't *on* in the first
place ;-) should be as simple as turning off -fnon-call-exceptions. Then
dereferences won't have flow edges and things can be reordered across
them. Unfortunately that will also have the side-effect of not
generating unwind info for leaf functions.
I'd actually be fairly surprised if you were able to measure any large
difference in performance between the two. Note that hopefully a
dereference will only have an edge the first time it is dereferenced.
So, loads of different fields from the same object etc are not subject
to this.
>(As an aside, it's hard to classify a "modern" processor... SPARC
>and IA-64 are in-order, and likely to remain that way.)
>
Meaning that it doesn't do any branch prediction/speculative execution
at all? Interesting.
regards
Bryce.
next prev parent reply other threads:[~2002-04-05 0:45 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
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 [this message]
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=3CACF360.4070209@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).