java aliasing rules

java aliasing rules

[Dan Nicolaescu]

Given this code:

class first  {  int i; char a;  char f1;  char f2; double d;};
class second {  char b;  char f2;  int f3;};


public class t
{
    public  void f (first  ps1, second ps2)
    {
        ps1.f1++;
        ps2.f2++;
        ps1.f1++;
        ps2.f2++;
    }
}

can it be assumed that given that "first" and "second" are
incompatible then ps1.f1 and ps2.f2 don't alias and we can generate
code like the following: (SPARC assembly)

        !#PROLOGUE# 0
        !#PROLOGUE# 1
        lduh    [%o1+14], %o0
        lduh    [%o2+10], %o3
        add     %o0, 2, %o0
        add     %o3, 2, %o3
        sth     %o0, [%o1+14]
        retl
        sth     %o3, [%o2+10]

instead of what is generated now: 

        !#PROLOGUE# 0
        !#PROLOGUE# 1
        lduh    [%o1+14], %o3
        add     %o3, 1, %o3
        sth     %o3, [%o1+14]
        lduh    [%o2+10], %o0
        add     %o0, 1, %o0
        sth     %o0, [%o2+10]
        lduh    [%o1+14], %o3
        add     %o3, 1, %o3
        sth     %o3, [%o1+14]
        lduh    [%o2+10], %o0
        add     %o0, 1, %o0
        retl
        sth     %o0, [%o2+10]


The more general question is if 2 COMPONENT_REFs that refer to classes
that are in conflicting alias sets (ie alias_sets_conflict_p) alias in
java. I have a hunch that this might be true, but I don't know enough
about java to be sure.  If the above is not true, is there a
restricted case when it is true?


(for the curious this is related to the patch at
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00576.html that is not
totally correct for C, but I have a hunch that it might be OK for
java, if that is the case I will change the patch to be language
specific).

Re: java aliasing rules

[Tom Tromey]

>>>>> "Dan" == Dan Nicolaescu <dann@godzilla.ICS.UCI.EDU> writes:

Dan> Given this code:
Dan> class first  {  int i; char a;  char f1;  char f2; double d;};
Dan> class second {  char b;  char f2;  int f3;};

Dan> public class t
Dan> {
Dan>     public  void f (first  ps1, second ps2)
Dan>     {
Dan>         ps1.f1++;
Dan>         ps2.f2++;
Dan>         ps1.f1++;
Dan>         ps2.f2++;
Dan>     }
Dan> }

Dan> can it be assumed that given that "first" and "second" are
Dan> incompatible

Yes.

Dan> The more general question is if 2 COMPONENT_REFs that refer to
Dan> classes that are in conflicting alias sets (ie
Dan> alias_sets_conflict_p) alias in java. I have a hunch that this
Dan> might be true, but I don't know enough about java to be sure.  If
Dan> the above is not true, is there a restricted case when it is
Dan> true?

My understanding, and please if you don't mind clear things up if I'm
wrong, is that each front end is free to write its own aliasing
function.  And as far as I know gcj doesn't have one.  So I don't know
how conflicting alias sets for Java are currently computed, but I
imagine it is just very conservative and doesn't follow the language
rules.

Better aliasing support is definitely something we'd like.  It's on my
to-do list (and, I'd wager, Bryce's), but I haven't had time to look
at it.

Anyway, in Java, casts are *always* done according to the type system.
There is no way to circumvent it.  So in your above example, it is
never possible to turn a `first' into a `second' -- they are not
compatible.

Does this answer your questions?

Tom

Re: java aliasing rules

[Bryce McKinlay]

Dan Nicolaescu wrote:

>The more general question is if 2 COMPONENT_REFs that refer to classes
>that are in conflicting alias sets (ie alias_sets_conflict_p) alias in
>java. I have a hunch that this might be true, but I don't know enough
>about java to be sure.
>

Right - Aliasing in Java is very simple, because basically there isn't 
any ;-). The only case we need to be careful about is with inheritance 
when two fields in different classes might actually be the same (ie if 
"class second extends first").

I implemented java_get_alias_set() by simply assigning a new alias set 
to every unique field, storing it in DECL_POINTER_ALIAS_SET for each 
FIELD_DECL. This managed to eliminate some redundant loads in my tests, 
but didn't cause any measurable improvements in benchmark scores so I 
didn't get too excited about it, and I didn't get around to submitting 
the patch yet. I'll try it out later on your test case and see what 
happens...

regards

Bryce.

Re: java aliasing rules

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

Dan> The more general question is if 2 COMPONENT_REFs that refer to
Dan> classes that are in conflicting alias sets (ie
Dan> alias_sets_conflict_p) alias in java. I have a hunch that this
Dan> might be true, but I don't know enough about java to be sure.  If
Dan> the above is not true, is there a restricted case when it is
Dan> true?

Tom> My understanding, and please if you don't mind clear things up if I'm
Tom> wrong, is that each front end is free to write its own aliasing
Tom> function.  And as far as I know gcj doesn't have one.  So I don't know
Tom> how conflicting alias sets for Java are currently computed, but I
Tom> imagine it is just very conservative and doesn't follow the language
Tom> rules.

Yes, a language can define it's own alias set function, if it doesn't
alias sets will be computed based on the contents of the type. 

For example 

class one {int i;};
class two {int i;};

will be put in the same alias set even though, AFAIK, they are not
compatible. 

Tom> Better aliasing support is definitely something we'd like.  It's on my
Tom> to-do list (and, I'd wager, Bryce's), but I haven't had time to look
Tom> at it.

IMHO this might be as simple as a < 5 lines function (but I might be
wrong...)
Dealing with the the example above will take you a long way (I'd be
glad to help if you need it).

But all this is unrelated to my question. 
In my first mail the "first" and "second" were already in different
alias sets. 

Tom> Anyway, in Java, casts are *always* done according to the type system.
Tom> There is no way to circumvent it.  So in your above example, it is
Tom> never possible to turn a `first' into a `second' -- they are not
Tom> compatible.
Tom> 
Tom> Does this answer your questions?

Yes, this is exactly I wanted to know. 

Could you test the following hack (I'll create a proper langhook
later) on a big java program and see if it makes a difference? 
(it made cc1 1% smaller, and I expect even more on java). 

Just set the COMPONENT_REF_ALIAS environment variable and recompile
the program... 

Index: alias.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/alias.c,v
retrieving revision 1.167
diff -c -3 -p -c -r1.167 alias.c
*** alias.c	2002/03/11 18:01:53	1.167
--- alias.c	2002/03/27 23:48:58
*************** nonoverlapping_component_refs_p (x, y)
*** 1810,1815 ****
--- 1855,1887 ----
  {
    tree fieldx, fieldy, typex, typey, orig_y;
  
+   /* Component refs that belong to structures that are known not to
+      alias, don't alias.  */
+   if (getenv ("COMPONENT_REF_ALIAS"))
+     {
+       typex = DECL_CONTEXT (TREE_OPERAND (x, 1));
+       typey = DECL_CONTEXT (TREE_OPERAND (y, 1));
+       if (typex != NULL && typey != NULL
+           && TREE_CODE (typex) == RECORD_TYPE
+           && TREE_CODE (typey) == RECORD_TYPE              
+           && ! alias_sets_conflict_p (get_alias_set (typex),
+                                       get_alias_set (typey)))
+         {
+               return 1;
+         }
+ 
+     }
    do
      {
        /* The comparison has to be done at a common type, since we don't

Re: java aliasing rules

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

Bryce> I implemented java_get_alias_set() by simply assigning a new
Bryce> alias set to every unique field, storing it in
Bryce> DECL_POINTER_ALIAS_SET for each FIELD_DECL. This managed to
Bryce> eliminate some redundant loads in my tests, but didn't cause
Bryce> any measurable improvements in benchmark scores so I didn't get
Bryce> too excited about it

This sounds like a nice approach.
My only question is how it handles the length field of an array.

Object[].length and Foo[].length can alias.
But int[].length and Object[].length cannot.

Similarly for the interior of arrays.

Maybe we could squeeze out some tiny percentage improvement by taking
this into account too?

Tom

Re: java aliasing rules

[Tom Tromey]

>>>>> "Dan" == Dan Nicolaescu <dann@godzilla.ICS.UCI.EDU> writes:

Dan> Could you test the following hack (I'll create a proper langhook
Dan> later) on a big java program and see if it makes a difference?

Right now I'm focusing just on 3.1.  It will take me some time before
I can get to this.

You could try building libgcj itself with it.  That qualifies as "big
java program" :-).  It's easy to do on many platforms.

If you want more, there are a bunch of ready-to-build programs here:

    http://sources.redhat.com/rhug/

Tom

Re: java aliasing rules

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

Tom> You could try building libgcj itself with it.  That qualifies as "big
Tom> java program" :-).  It's easy to do on many platforms.

I've tried that on sparc-sun-solaris2.7 and the difference was
insignificant.  :-(

Re: java aliasing rules

[Bryce McKinlay]

[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]

Tom Tromey wrote:

>Bryce> I implemented java_get_alias_set() by simply assigning a new
>Bryce> alias set to every unique field, storing it in
>Bryce> DECL_POINTER_ALIAS_SET for each FIELD_DECL. This managed to
>Bryce> eliminate some redundant loads in my tests, but didn't cause
>Bryce> any measurable improvements in benchmark scores so I didn't get
>Bryce> too excited about it
>
>This sounds like a nice approach.
>My only question is how it handles the length field of an array.
>
>Object[].length and Foo[].length can alias.
>But int[].length and Object[].length cannot.
>

I believe the array length field is not important for aliasing purposes 
because it is read-only.

>Similarly for the interior of arrays.
>
>Maybe we could squeeze out some tiny percentage improvement by taking
>this into account too?
>

I think we can make sure arrays of different primitive types get 
different alias sets. It might also be possible to make sure that A[] 
and B[] are known not to alias when A and B do not extend each other.

For Dan's test case, I can get optimal code simply by setting 
DECL_NONADDRESSABLE_P on all Java FIELD_DECLS (see the patch below), 
there's doesn't seem to be any need for java_get_alias_set or changes to 
the generic alias code to get this.

On PowerPC, before this patch I got:

t.f(first, second):
        lhz 9,10(4)      #  <variable>.f1
        addi 9,9,1
        sth 9,10(4)      #  <variable>.f1
        lhz 11,6(5)      #  <variable>.f2
        addi 11,11,1
        sth 11,6(5)      #  <variable>.f2
        lhz 9,10(4)      #  <variable>.f1
        addi 9,9,1
        sth 9,10(4)      #  <variable>.f1
        lhz 11,6(5)      #  <variable>.f2
        addi 11,11,1
        sth 11,6(5)      #  <variable>.f2
        blr

and with DECL_NONADDRESSABLE_P:

t.f(first, second):
        lhz 9,10(4)      #  <variable>.f1
        lhz 11,6(5)      #  <variable>.f2
        addi 9,9,2
        addi 11,11,2
        sth 9,10(4)      #  <variable>.f1
        sth 11,6(5)      #  <variable>.f2
        blr

regards

Bryce.


[-- Attachment #2: java-alias-4.patch --]
[-- Type: text/plain, Size: 2723 bytes --]

Index: class.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/class.c,v
retrieving revision 1.130
diff -u -r1.130 class.c
--- class.c	2002/03/03 14:07:32	1.130
+++ class.c	2002/03/29 05:36:33
@@ -762,6 +762,10 @@
   TREE_CHAIN (field) = TYPE_FIELDS (class);
   TYPE_FIELDS (class) = field;
   DECL_CONTEXT (field) = class;
+  
+  /* It is not possible to take the address of a field. */
+  if (TREE_CODE (field) == FIELD_DECL)
+    DECL_NONADDRESSABLE_P (field) = 1;
 
   if (flags & ACC_PUBLIC) FIELD_PUBLIC (field) = 1;
   if (flags & ACC_PROTECTED) FIELD_PROTECTED (field) = 1;
@@ -1858,6 +1862,7 @@
 	  TREE_CHAIN (dummy) = tmp_field;
 	  DECL_CONTEXT (tmp_field) = dtype;
 	  DECL_ARTIFICIAL (tmp_field) = 1;
+	  DECL_NONADDRESSABLE_P (tmp_field) = 1;
 	  dummy = tmp_field;
 	}
 
@@ -1868,6 +1873,7 @@
 	  TREE_CHAIN (dummy) = tmp_field;
 	  DECL_CONTEXT (tmp_field) = dtype;
 	  DECL_ARTIFICIAL (tmp_field) = 1;
+	  DECL_NONADDRESSABLE_P (tmp_field) = 1;
 	  dummy = tmp_field;
 	}
 
@@ -1903,6 +1909,7 @@
   TYPE_FIELDS (this_class) = base_decl;
   DECL_SIZE (base_decl) = TYPE_SIZE (super_class);
   DECL_SIZE_UNIT (base_decl) = TYPE_SIZE_UNIT (super_class);
+  DECL_NONADDRESSABLE_P (base_decl) = 1;
 }
 
 /* Handle the different manners we may have to lay out a super class.  */
Index: java-tree.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/java-tree.h,v
retrieving revision 1.142
diff -u -r1.142 java-tree.h
--- java-tree.h	2002/03/27 18:28:02	1.142
+++ java-tree.h	2002/03/29 05:36:39
@@ -1592,6 +1592,7 @@
   else TREE_CHAIN(FIELD) = tmp_field; \
   DECL_CONTEXT (tmp_field) = RTYPE; \
   DECL_ARTIFICIAL (tmp_field) = 1; \
+  DECL_NONADDRESSABLE_P (tmp_field) = 1; \
   FIELD = tmp_field; }
 
 #define FINISH_RECORD(RTYPE) layout_type (RTYPE)
Index: typeck.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/typeck.c,v
retrieving revision 1.44
diff -u -r1.44 typeck.c
--- typeck.c	2001/12/03 23:09:42	1.44
+++ typeck.c	2002/03/29 05:37:07
@@ -433,12 +433,15 @@
   FIELD_PUBLIC (fld) = 1;
   FIELD_FINAL (fld) = 1;
   TREE_READONLY (fld) = 1;
+  DECL_NONADDRESSABLE_P (fld) = 1;
 
   atype = build_prim_array_type (element_type, length);
   arfld = build_decl (FIELD_DECL, get_identifier ("data"), atype);
   DECL_CONTEXT (arfld) = t;
   TREE_CHAIN (fld) = arfld;
   DECL_ALIGN (arfld) = TYPE_ALIGN (element_type);
+  DECL_NONADDRESSABLE_P (arfld) = 1;
+  TYPE_NONALIASED_COMPONENT (atype) = 1;
 
   /* We could layout_class, but that loads java.lang.Object prematurely.
    * This is called by the parser, and it is a bad idea to do load_class

Re: java aliasing rules

[Richard Henderson]

On Fri, Mar 29, 2002 at 06:02:46PM +1200, Bryce McKinlay wrote:
> For Dan's test case, I can get optimal code simply by setting 
> DECL_NONADDRESSABLE_P on all Java FIELD_DECLS (see the patch below), 

Ah yes.  This looks right.


r~

Re: java aliasing rules

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

Bryce> I believe the array length field is not important for aliasing
Bryce> purposes because it is read-only.

Thanks.

Bryce> For Dan's test case, I can get optimal code simply by setting
Bryce> DECL_NONADDRESSABLE_P on all Java FIELD_DECLS (see the patch
Bryce> below), there's doesn't seem to be any need for
Bryce> java_get_alias_set or changes to the generic alias code to get
Bryce> this.

That's a nice patch!

Tom

Re: java aliasing rules

[Bryce McKinlay]

Tom Tromey wrote:

>Bryce> For Dan's test case, I can get optimal code simply by setting
>Bryce> DECL_NONADDRESSABLE_P on all Java FIELD_DECLS (see the patch
>Bryce> below), there's doesn't seem to be any need for
>Bryce> java_get_alias_set or changes to the generic alias code to get
>Bryce> this.
>
>That's a nice patch!
>

Unfortunately the code generated is not entirely correct for Java. The 
reason is nothing to do with aliasing but rather NullPointerExceptions.

  public  void f (first  ps1, second ps2)
  {
      ps1.f1++;
      ps2.f2++;
      ps1.f1++;
      ps2.f2++;
  }

t.f(first, second):
       lhz 9,10(4)      #  <variable>.f1
       lhz 11,6(5)      #  <variable>.f2
       addi 9,9,2
       addi 11,11,2
       sth 9,10(4)      #  <variable>.f1
       sth 11,6(5)      #  <variable>.f2
       blr


With this code, if "ps2" is null then the second load (lhz) will throw 
before the ps1.f1 is seen as incremented. The optimal, correct code for 
Java is really something like:

lhz r9, [ps1.f1]
addi r9,r9,1
sth r9, [ps1.f1]
lhz r11, [ps2.f2]
addi r9,r9,1
addi r11,r11,2
sth r9, [ps1.f1]
sth r11, [ps2.f2]
blr

The second increment of ps1.f1 should not be allowed to be 
moved/combined ahead of the first "ps2.f2++", because it can trap/throw. 
The last two lines however cannot trap (since the first two would have 
done so already), so they can be safely moved/combined with other 
instructions)

None the less, I'm tempted to check in (to mainline) the 
DECL_NONADDRESSABLE_P change anyway, along with a PR and test case for 
the nullpointer problem. This is really just exposing a problem 
elsewhere in the compiler, which quite likely happens anyway in other 
situations when the aliasing stuff doesn't prevent it. Its also highly 
unlikely that any real applications are going to care about this 
behaviour, and exposing the problem will make it easier to fix it. What 
do you guys think?

regards

Bryce.

Re: java aliasing rules

[Richard Henderson]

On Sat, Mar 30, 2002 at 11:22:28AM +1200, Bryce McKinlay wrote:
> The second increment of ps1.f1 should not be allowed to be 
> moved/combined ahead of the first "ps2.f2++", because it can trap/throw. 

Hum.  That's ugly.  The scheduling problem can be handled
easily.  Fixing global optimizations without practically
disabling them is harder.

> [ check it in to mainline anyway ]
> What do you guys think?

Sounds good.


r~

Re: java aliasing rules

[Jeff Sturm]

On Sat, 30 Mar 2002, Bryce McKinlay wrote:
> With this code, if "ps2" is null then the second load (lhz) will throw 
> before the ps1.f1 is seen as incremented.

That's a shame.

> 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.

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.

Jeff

Re: java aliasing rules

[Richard Henderson]

On Sat, Mar 30, 2002 at 09:35:54AM -0500, Jeff Sturm wrote:
> Wouldn't accessing r9 immediately after the load cause a pipeline stall?

Yes.

> 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.

Yes.  All the instructions before hand are committed, and all
of the in-flight instruction after are aborted.


r~

Re: java aliasing rules

[Bryce McKinlay]

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.

Re: java aliasing rules

[Jeff Sturm]

On Sun, 31 Mar 2002, Bryce McKinlay wrote:
> >>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.

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.

(As an aside, it's hard to classify a "modern" processor...  SPARC
and IA-64 are in-order, and likely to remain that way.)

Jeff

Re: java aliasing rules

[Andrew Haley]

Jeff Sturm writes:
 > On Sun, 31 Mar 2002, Bryce McKinlay wrote:
 > > >>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.

If it doesn't annul such speculation on SEGV I don't think it's
correct Java semantics.

 > Am I correct in thinking this is only an issue for -fnon-call-exceptions?

Yes.

 > 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.

I know what you mean, but turning this off is a pretty major departure
from the Java language spec.

Andrew.

Re: java aliasing rules

[Jeff Sturm]

On Thu, 4 Apr 2002, Andrew Haley wrote:
>  > > 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.
> 
> If it doesn't annul such speculation on SEGV I don't think it's
> correct Java semantics.

I've been told that EV6 does, don't know about others.  (CPUs are complex
beasts nowadays, that's for sure.)

>  > 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.
> 
> I know what you mean, but turning this off is a pretty major departure
> from the Java language spec.

Perhaps.  There are days I wonder if Java is the language I need.  What
I'd really like is Java that easily binds to C++ code... um, never
mind ;)

Jeff

Re: java aliasing rules

[Bryce McKinlay]

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.

Re: java aliasing rules

[Jeff Sturm]

On Fri, 5 Apr 2002, Bryce McKinlay wrote:
> 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.

Well, sure... leaf functions have no use for unwind info if they will
never throw.

> 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. 

Agreed.  It may be hard to measure all right, I find that "real" Java
programs usually suffer from other bottlenecks like synchronization or GC.

For that matter I don't know if there are any large general improvements
to be made in gcj.  Most of the low-hanging fruit are gone.

> >(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.

Yes, but isn't there a little more to OoO than that?  Like reordering
instructions to avoid data hazards and cache misses?

Jeff

Re: java aliasing rules

[Bryce McKinlay]

Jeff Sturm wrote:

>On Fri, 5 Apr 2002, Bryce McKinlay wrote:
>
>>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.
>>
>
>Well, sure... leaf functions have no use for unwind info if they will
>never throw.
>

Right but you get an abort instead of a NullPointerException with maybe 
not-quite-perfect semantics. Probibly this is easily fixed though.

>>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. 
>>
>
>Agreed.  It may be hard to measure all right, I find that "real" Java
>programs usually suffer from other bottlenecks like synchronization or GC.
>
>For that matter I don't know if there are any large general improvements
>to be made in gcj.  Most of the low-hanging fruit are gone.
>

I think major improvements can still be made to type checking, both by 
avoiding them and speeding them up in the first place (ie inlining the 
simple ones and optimizing the layout of class info).  Method inlining 
could be vastly improved. Automatic bounds check elimination could speed 
things up a lot. I have a patch to do inline divide checking instead of 
using the divide subroutine which speeds some tests up by 4X on powerpc.

regards

Bryce.