public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
To: tromey@redhat.com
Cc: Dan Nicolaescu <dann@godzilla.ics.uci.edu>,
	java@gcc.gnu.org, gcc@gcc.gnu.org
Subject: Re: java aliasing rules
Date: Thu, 28 Mar 2002 22:02:00 -0000	[thread overview]
Message-ID: <3CA40386.5030106@waitaki.otago.ac.nz> (raw)
In-Reply-To: <87vgbhij40.fsf@creche.redhat.com>

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

  reply	other threads:[~2002-03-29  6:02 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 [this message]
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
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=3CA40386.5030106@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=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).