I'm new and wanting to help!

[Tom Tromey]

Jon> Unfortunately, I don't get scared off easy :P

:-)

Jon> If you could send me both of those optimization passes, that would be
Jon> terrific.  I'll look at them and see if I can do anything.  If not,
Jon> I'll figure it out :)

Cool.

I've attached a patch and a couple of files.

The patch adds some needed support for devirtualization.  (I think
part of it is already in the tree -- the java-tree.def bit.)
Basically it wraps virtual and interface method invocations in
OBJ_TYPE_REF trees, so that we can more easily detect them later.

The first file implements devirtualization.  The idea is that if we
know something about the runtime type of an object, we can "strength
reduce" calls, either virtual->nonvirtual, or interface->virtual.

As I recall right now it is very lame, as in it only looks at calls on
objects which were allocated with 'new Something'.  (I thought maybe I
changed this but I didn't read the code today to see...)
One way I tried this was to add a printf to the pass and then rebuild
the library; that let me see how often the optimization triggered...


The second file implements "invariant propagation".  The idea is that
some things, like the vtable pointer or the length field of an array,
cannot change in java.  So, we can collapse these to their first
(dominating) load.

Arguably this should be done in a non-gcj-specific way in GCC.  That
would mean adding some way to explain this property in the trees and
then making sure the optimizers can handle it properly.

Note that this isn't quite enough to handle array bounds check
elimination -- this pass works around the "aliasing problem" mentioned
in the PR, but then, apparently, the optimizers (VRP I think) don't
realize the real meaning of our unsigned comparison trick ... fixing
this probably requires either changing gcj not to emit the unsigned
comparison (but in this case we'd want to recapture this optimization
later on) or changing the appropriate tree optimizer.


As I recall one or both of these passes will crash on some files in
libjava.

How to get these in is an open problem.  I'm sure we don't want to
check in the hack that is currently used to register the passes.

Tom

-------------- next part --------------
A non-text attachment was scrubbed...
Name: My-devirt-patch
Type: application/octet-stream
Size: 7370 bytes
Desc: devirt patch
URL: <http://gcc.gnu.org/pipermail/java/attachments/20060803/4a5d9976/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tree-ssa-devirt.c
Type: application/octet-stream
Size: 10527 bytes
Desc: tree-ssa-devirt.c
URL: <http://gcc.gnu.org/pipermail/java/attachments/20060803/4a5d9976/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tree-ssa-invariant.c
Type: application/octet-stream
Size: 7674 bytes
Desc: tree-ssa-invariant.c
URL: <http://gcc.gnu.org/pipermail/java/attachments/20060803/4a5d9976/attachment-0002.obj>