Re: [tree-ssa] Remove useless null pointer checks

[law at redhat dot com]

In message <Pine.LNX.4.44.0307310042150.32603-100000@ops2.one-point.com>, Jeff 
Sturm writes:
 >On Wed, 30 Jul 2003 law@redhat.com wrote:
 >>  >Somehow the RTL optimizers never caught on to this.
 >> Odd.  We've got a pass do do this at the RTL level and from the structure
 >> of your code I'd expect it to remove the useless check.  Very odd.
 >
 >Because delete_null_pointer_checks_1 can't cope with a COMPONENT_REF,
 >perhaps?  The test for loads:
 >
 >          if (GET_CODE (SET_SRC (set)) == MEM
 >              && GET_CODE ((reg = XEXP (SET_SRC (set), 0))) == REG
 >
 >won't match:
 >
 >    (set (reg:SI 61)
 >        (mem/s:SI (plus:SI (reg/v/f:SI 59 [ a ])
 >                (const_int 8 [0x8])) [7 <variable>.i+0 S4 A32]))
Ah.   Yes.  This has been extensively discussed in the past.

Way back when I wrote the null pointer check removal code we didn't have
the ability to map an address back to the original object.  So given
an address like (plus (reg) (const)) we couldn't necessarily make the
assumption that (reg) actually pointed to an object and that the
(const_int) portion was just accessing a field within the object
(or an array element).

Thus given such an address, you really didn't know anything about the
value of (reg) and we were unable to apply the optimization.  OK, you
do know something about (reg) -- it can't have the value -8 :-)

These days we may be able to map back to a real object's address in
which case we could probably make the RTL null pointer checking code more
aggressive.  Though I doubt it's worth the effort given that we have
the same capability in tree-ssa.

tree-ssa works differently in that we have direct access to the underlying
objects -- ie, we haven't lowered to pointer arithmetic.  Access to that
object allows us to be more aggressive.

jeff