On Mon, Nov 7, 2011 at 11:16 AM, Richard Guenther
<richard.guent...@gmail.com> wrote:
> 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).
Oh, and points-to plus DSE/DCE might confuse your pass as stores that
points-to can prove go "nowhere" are removed.
int main()
{
int *p = 0;
*p = 1;
}
with -fno-tree-ccp we remove the store (ugh, I suppose we should not
do that ;)).
Richard.
> Richard.
>
