Re: [tree-ssa/java] remaining null-pointer-check hits

[law at redhat dot com]

In message <20040419210325.GA8628@redhat.com>, Richard Henderson writes:
 >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.
Odd, there was one known case where we missed a null pointer check when
compiling alias.c IIRC.    In that particular case we had multiple paths,
each of which dereferenced a different instance of a particular pointer.
Those instances were then joined via a PHI node, then soon thereafter we
checked the result of the PHI against NULL.

Since we don't track the non-null property though PHIs we were unable to
detect that case.

 >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.
Alternately, we could walk back the DEF-USE chains for field.530_59 and mark
its feeding values as being non-null as well.  This is just another instance
where nop casts are getting in the way and we really ought to handle them
better in the optimizers.

 >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
 >seen
 >
 >  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.
Seems reasonable as well.
jeff