On Mon, Nov 7, 2011 at 11:07 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Mon, Nov 07, 2011 at 02:55:02AM -0700, Jeff Law wrote:
>> [ Working virtually from Hawaii tonight... :-) ]
>
> ;)
>
>> You might legitimately wonder how often this triggers. A GCC 4.6.0
>> checking-enabled compiler sees a .64% codesize improvement from this
>> optimization. That's an awful lot of unexecutable code. The NULL
>> references come from the VEC implementation and a variety of other
>> sources.
>
> I'd say it is a good idea, though I wonder if the gate shouldn't
> also use && flag_delete_null_pointer_checks or at least if the default
> for this new option shouldn't be based on flag_delete_null_pointer_checks.
> -fno-delete-null-pointer-checks is documented for quite some time as an option
> which allows NULL pointer dereferences (and AFAIK AVR uses it) and
> people who use that option will most likely want to disable this
> optimization too.
I also wonder if instead of a new pass control-dependent DCE can
be taught of this? At least I presume that this code removal can
expose DCE opportunities and DCE can expose these code removal
opportunities?
Did you consider simplifying the code by simply relying on
points-to analysis? Thus for the dereferenced SSA name check
pi = SSA_NAME_PTR_INFO (name);
if (pi
&& pt_solution_empty_p (&pi->pt))
...
? I once implemented a warning to warn about such derefrences,
but it (of course ...) triggers for all the unexecutable code paths...
points-to should be both more precise (it tracks uninitialized pointers
and it tracks memory) and less precise (because it's only flow-sensitive
for SSA names).
Richard.
