This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA][PATCH] Isolate erroneous paths optimization
- From: Ian Lance Taylor <iant at google dot com>
- To: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Cc: Jeff Law <law at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>
- Date: Wed, 6 Nov 2013 06:24:28 -0800
- Subject: Re: [RFA][PATCH] Isolate erroneous paths optimization
- Authentication-results: sourceware.org; auth=none
- References: <5271F493 dot 4020308 at redhat dot com> <CAFiYyc2tFbaTq4xr8xZA5wb_m9pB4+VA-9MkmNDXTVkP2gQdBA at mail dot gmail dot com> <52785087 dot 3060908 at redhat dot com> <CAKOQZ8x5FAnYzkepikoJSpX9467H0Xx_28SO3abGu6J+PSpNEQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1311060743550 dot 4174 at laptop-mg dot saclay dot inria dot fr>
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.
Ian