This is the mail archive of the
mailing list for the GCC project.
[tree-ssa/java] remaining null-pointer-check hits
- From: Richard Henderson <rth at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Cc: java at gcc dot gnu dot org
- Date: Mon, 19 Apr 2004 14:03:25 -0700
- Subject: [tree-ssa/java] remaining null-pointer-check hits
I instrumented the compiler to report successful optimizations by
the rtl-level delete_null_pointer_checks code. The only hits are
from the Java front end.
For the record, the missed optimization appears to be of the form:
field.2904_815 = T.527_48 (T.521_41, name_42);
field.530_59 = (struct java.lang.Object *)field.2904_815;
T.531_60 = field.530_59->vtable;
if (field.2904_815 != 0B) goto <L26>; else goto <L29>;
I.e. we have a cast at the tree level that obscures the dereference
that ocurred with with the given pointer data.
Also for the record, there were a total of 54 hits in libjava. So
not *that* many should we decide to remove the rtl level optimizer
without having finished a tree-level replacement.
An alternate solution that perhaps would require no changes to the
tree-level optimizers at all is adjusting the structure of the Java
front-end output such that we don't need the cast. I.e. we'd have
T.531_60 = field.2904_815->some.base.object.vtable
at which point we infer the non-zero property against field.2904_815
directly and remove a temporary cluttering the statement stream.
Cc'd to the java list to see how practical this might be.