This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa/java] remaining null-pointer-check hits
- From: law at redhat dot com
- To: Steven Bosscher <stevenb at suse dot de>
- Cc: gcc at gcc dot gnu dot org, java at gcc dot gnu dot org
- Date: Tue, 04 May 2004 12:56:34 -0600
- Subject: Re: [tree-ssa/java] remaining null-pointer-check hits
- Reply-to: law at redhat dot com
In message <email@example.com>, Steven Bosscher writes:
>> 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.
>Isn't this something ccp can do instead? Or did you add this to keep
>all the null checks together in one file? It's a bit unintiutive that
>DOM would have to look through dominance frontiers ;-)
CCP could do it as well. CCP could in fact do just about any propagation
that DOM currently does. In fact const/copy propagation CCP is just a more
aggressive version of what is currently done by DOM.
It's _easier_ to do it in DOM as we've already got all the little bits
which tell us that a particular statement used a particular SSA_NAME in
a way which guarantees that the SSA_NAME has a nonzero value.
>> 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) ...
>How many of these appear in other important software (e.g. kernel, glibc,
Unknown at this time. However, I would expect that number to be quite
small. It'll be easy enough to check. And again, if it turns out there's
significant numbers of these still lying around it's simply a matter of
plugging in the right code into a global propagation framework.