Bug 21856 - null pointer check elimination
Summary: null pointer check elimination
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.1.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: missed-optimization
: 24242 (view as bug list)
Depends on: 20318
Blocks: 58689
  Show dependency treegraph
Reported: 2005-06-01 01:58 UTC by Tom Tromey
Modified: 2016-09-30 22:50 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2006-04-08 01:24:01


Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey 2005-06-01 01:58:24 UTC
Sometimes we emit explicit null pointer checks.  On some platforms we
do this for every member reference; many of these should be trivial to
eliminate.  On x86 Linux, we only do this in one special case, which
is checking the 'this' argument to a final method call with the non-BC

Here's a test case:

public class z
  public final void m() { System.out.println("m"); }
  public void nothing() { }

  public static void main(String[] args)
    z val = new z();

When I compile this with -S ("gcj -O0 -S z.java"), I see an explicit
check and conditional call to _Jv_ThrowNullPointerException before the
`val.m()' invocation.  However, we know that this is redundant, as
'val.nothing()' would have thrown if val==null.

The situation here may be complicated by the fact that a java program
can catch NullPointerException.  In this test case, it is invalid to
optimize away the check when val.m() is called:

public abstract class z
  public final void m() { System.out.println("m"); }
  public void nothing() { }
  public abstract z get_one();

  public static void main(String[] args)
    z val = get_one();
    try {
    } catch (NullPointerException _) {

One more wrinkle in this area is that on some platforms (all the
well-supported ones like x86 Linux), we do not emit explicit null
checks.  Instead we just let them SEGV and at runtime convert this
into an exception.  On these platforms we compile java code with

However, I would expect we could get better optimizations later on if
we could notice that some of these references can never be made via a
null base pointer.  For this to work, I think there would have to be a
way to tell RTL about the difference between a possibly-trapping and a
never-trapping load.  I know basically zero about RTL so I don't know
if this is realistic at this point.

If you compile the two "z.java" test cases for some
less-well-supported target, you will see explicit null pointer checks
at each call site.  I'm not sure if we emit tests for references via
'this' -- I think we have an ad hoc optimization for it.

Another thing we can recognize is that 'new' never returns null.  We
set DECL_IS_MALLOC on the function we use to create objects and
arrays, though I suppose that wouldn't suffice.  These functions are
declared in decl.c, just search for DECL_IS_MALLOC there (there are a
few instances).  I don't know of a way for the front end to inform
later passes about this property of 'new'.
Comment 1 Andrew Pinski 2005-06-01 20:29:40 UTC
Confirmed, see PR 20318 for information about an attribute which we should be adding soon.
Comment 2 Andrew Pinski 2005-11-12 20:08:48 UTC
Comment 3 Andrew Pinski 2005-11-12 20:09:05 UTC
*** Bug 24242 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Pinski 2006-01-09 18:34:10 UTC
No longer working on this, I am too busy working on the gfortran front-end.
Comment 5 Andrew Pinski 2016-09-30 22:50:32 UTC
Closing as won't fix as the Java front-end has been removed from the trunk.