This is the mail archive of the java@gcc.gnu.org mailing list for the Java 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]

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


In message <5AEBE522-93EF-11D8-B035-000393A6D2F2@physics.uc.edu>, Andrew Pinski
 writes:
 >On Apr 19, 2004, at 17:03, Richard Henderson wrote:
 >> 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
 >
 >
 >Most likely this is also how the C++ front-end need the same thing
 >because I see many casts in there and also SRA will not be able
 >to work correctly without it being this way.
Like so many things it's probably wise to attack this from both directions.
Namely fixing the optimizers to deal with these casts _and_ fixing the
front-ends to avoid the casts when possible.

I've got the changes necessary to allow DOM to see through these casts
(it's only a few lines of code).  This picks up most of the cases where
the RTL null pointer check elimination code was finding something useful
to do.

I've also made a trivial extension to DOM which allows it to propagate the
non-null property through PHI nodes.  ie, if all arguments to a PHI node
are known to be nonzero, then the result of the PHI node must also be
nonzero.  That fixed the half-dozen cases we missed in GCC itself.

The net result is we're left one case we're not handling.  Specifically if
we have multiple paths where a pointer is dereferenced and there is no
PHI node at their join point.  ie

    BLOCK1      BLOCK 2
   p1->field   p1->field
       \          /
        \        /
         \      /
          \    /
          BLOCK 3
          if (p1) ...


P1 will have the nonnull property at the end of block #1 and block #2, but
since there is no PHI at the head of block #3, we can't propagate the nonnull
property into block #3.

Anyway, I'll check these bits in once the merge is complete.  Barring 
objections I'll also wipe the RTL null pointer check elimination code.
The RTL version has become nearly worthless and if this one case we're
missing is _that_ important for someone I know how to address it :-)

jeff


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