Re: [RFA][PATCH] Isolate erroneous paths optimization

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Nov 6, 2013 at 3:24 PM, Ian Lance Taylor <iant@google.com> wrote:
> On Tue, Nov 5, 2013 at 10:50 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
>> On Tue, 5 Nov 2013, Ian Lance Taylor wrote:
>>
>>> This patch actually breaks the Go testsuite.  In Go dereferencing a
>>> nil pointer is well-defined: it causes panic that can be caught.  This
>>> breaks a test for that functionality by changing the panic to a
>>> builtin_trap.
>>>
>>> That's not a big deal; I'll just disable this optimization in the Go
>>> frontend.
>>
>>
>> Shouldn't go use -fno-delete-null-pointer-checks by default then? That
>> should disable this optimization and others that rely on the same idea.
>
> No, that is a different optimization with different properties.  The
> -fdelete-null-pointer-checks optimization assumes that if you write
>     x = *p;
>     if (p == NULL) { printf ("NULL\n"); }
> that the test p == NULL can not succeed.  In Go, that is true.  If p
> is NULL the *p will cause a panic and ordinary code execution will not
> proceed.
>
> The recent -fisolate-erroneous-paths optimization will change code
> like this:
>     if (p == NULL) { printf ("NULL\n"); }
>     x = *p;
> into code like this:
>     if (p == NULL) { printf ("NULL\n"); __builtin_trap (); }
>     x = *p;
> That is, it will insert a trap rather than dereferencing the pointer
> known to be NULL.  This doesn't work for Go because we really do want
> the panic, not the __builtin_trap.  This optimization would work fine
> for Go if there were a way to explicitly call the panic function
> rather than calling trap, but that would be a frontend-dependent
> aspect to a middle-end optimization.

But then you have -fnon-call-exceptions enabled?  Where obviously
-fisolate-erroneous-paths also shouldn't apply?

Richard.

> Ian