This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: java aliasing rules
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: tromey at redhat dot com, Dan Nicolaescu <dann at godzilla dot ics dot uci dot edu>, java at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Fri, 05 Apr 2002 12:44:16 +1200
- Subject: Re: java aliasing rules
- References: <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.