This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]