-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/09/11 15:10, Paolo Bonzini wrote:
> On 11/09/2011 06:53 PM, Jeff Law wrote:
>> My patch totally ignores the other code on the unexecutable path.
>> So we can miss externally visible side effects, if we were to
>> somehow get on the unexecutable p
On 11/09/2011 06:53 PM, Jeff Law wrote:
My patch totally ignores the other code on the unexecutable path. So
we can miss externally visible side effects, if we were to somehow get
on the unexecutable path. But that's the whole point, in a conforming
program we can't ever get on the unexecutable
On Wed, Nov 09, 2011 at 10:53:34AM -0700, Jeff Law wrote:
> > which is only different on undefined paths. But I'm not sure that
> > more complicated cases, where there are other instructions between
> > the "if" and "*p = 0", would also be allowed by the C standard.
> > For example, I think a func
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/09/11 01:09, Paolo Bonzini wrote:
> On 11/08/2011 09:24 PM, Jeff Law wrote:
>> We don't have access to those assertions as they're removed well
>> prior to this pass running. However, if we did, or if we had
>> redundant PHIs in the stream which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/09/11 02:00, Richard Guenther wrote:
>
>> So the question is do we want to proceed with any of this work?
>> If so I can update the patch, if not I'll go back to my warning
>> work :-)
>
> I think we do want to continue with this work - probabl
On Tue, Nov 8, 2011 at 8:47 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 15:25, Richard Guenther wrote:
>>
>> Indeed. We'd have to tell people that they cannot catch *(void *)0
>> = 0 with a SIGSEGV signal handler unless they compile with some
>> magic fla
On 11/08/2011 09:24 PM, Jeff Law wrote:
We don't have access to those assertions as they're removed well prior
to this pass running. However, if we did, or if we had redundant PHIs
in the stream which were propagated we'd be presented with something like
BB0 if (p_1) goto BB1 else goto BB2
BB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/11 13:15, Paolo Bonzini wrote:
> On 11/08/2011 08:29 PM, Jeff Law wrote:
>>> Just to understand, what does this do with your optimization?
>>>
>>> void f(void *p) { if (p) { puts("sell_soul_to_devil");
>>> puts("post_reload_rewrite"); }
>>>
On 11/08/2011 08:29 PM, Jeff Law wrote:
Just to understand, what does this do with your optimization?
void f(void *p) {
if (p) {
puts("sell_soul_to_devil"); puts("post_reload_rewrite"); }
*p = 2; }
... f(NULL);
Does the program sell its soul to the devil before crashing?
If "f" is not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 15:25, Richard Guenther wrote:
>
> Indeed. We'd have to tell people that they cannot catch *(void *)0
> = 0 with a SIGSEGV signal handler unless they compile with some
> magic flag. Thus, the question is whether we want to optimize
> thin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/11 04:18, Paolo Bonzini wrote:
> On 11/07/2011 07:54 PM, Jeff Law wrote:
>> But we're still stuck with the conditional leading to the path
>> with the __builtin_trap. That's what we want to avoid since
>> those conditionals are executed at ru
On 11/07/2011 07:54 PM, Jeff Law wrote:
But we're still stuck with the conditional leading to the path with
the __builtin_trap. That's what we want to avoid since those
conditionals are executed at runtime.
Just to understand, what does this do with your optimization?
void f(void *p)
{
if
On Mon, Nov 7, 2011 at 8:03 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 08:49, Richard Guenther wrote:
>
>>
>> OTOH I'm not sure we want to change a possible trap (And thus
>> program abort) to a fallthru ...
> I think this is the big question we need to a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 03:21, Richard Guenther wrote:
>
> Oh, and points-to plus DSE/DCE might confuse your pass as stores
> that points-to can prove go "nowhere" are removed.
I think this is OK in the sense that we may miss a case where we could
have detected
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 03:07, Jakub Jelinek 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-enab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 08:49, Richard Guenther wrote:
>
> OTOH I'm not sure we want to change a possible trap (And thus
> program abort) to a fallthru ...
I think this is the big question we need to answer; there's other
places were we rely upon ISO's standard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 08:54, Tom Tromey wrote:
>> "Jeff" == Jeff Law writes:
>
> Jeff> So, presumably there's no way to know we're throwing to Jeff>
> NullPointerException from the exception information attached to
> the Jeff> statement or BB? If not I co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 09:24, Richard Guenther wrote:
> On Mon, Nov 7, 2011 at 5:07 PM, Jeff Law wrote:
>
I also wonder if instead of a new pass control-dependent DCE
can be taught of this?
> It could. I'm not sure it really buys us anything e
On 11/07/2011 04:54 PM, Tom Tromey wrote:
"Jeff" == Jeff Law writes:
Jeff> So, presumably there's no way to know we're throwing to
Jeff> NullPointerException from the exception information attached to the
Jeff> statement or BB? If not I could disable if the statement with the
Jeff> memory
2011/11/7 Richard Guenther :
> On Mon, Nov 7, 2011 at 5:07 PM, Jeff Law wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>>>
>>> I also wonder if instead of a new pass control-dependent DCE can be
>>> taught of this?
>> It could. I'm not sure it really buys us anything except may
On Mon, Nov 7, 2011 at 5:07 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>>
>> I also wonder if instead of a new pass control-dependent DCE can be
>> taught of this?
> It could. I'm not sure it really buys us anything except maybe being
> able to reuse the pdom & con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> I also wonder if instead of a new pass control-dependent DCE can be
> taught of this?
It could. I'm not sure it really buys us anything except maybe being
able to reuse the pdom & control-dependency analysis.
It actually more naturally belongs
> "Jeff" == Jeff Law writes:
Jeff> So, presumably there's no way to know we're throwing to
Jeff> NullPointerException from the exception information attached to the
Jeff> statement or BB? If not I could disable if the statement with the
Jeff> memory op throws anywhere. It's not ideal, but c
On Mon, Nov 7, 2011 at 4:43 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 06:53, Tom Tromey wrote:
>>> "Jeff" == Jeff Law writes:
>>
>> Jeff> First, it's perfectly fine to have a NULL pointer dereference
>> in a Jeff> program as long as that code is nev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 06:53, Tom Tromey wrote:
>> "Jeff" == Jeff Law writes:
>
> Jeff> First, it's perfectly fine to have a NULL pointer dereference
> in a Jeff> program as long as that code is never executed. Once
> the code is Jeff> executed, we've ente
> "Jeff" == Jeff Law writes:
Jeff> First, it's perfectly fine to have a NULL pointer dereference in a
Jeff> program as long as that code is never executed. Once the code is
Jeff> executed, we've entered the realm of undefined behavior.
Jeff> Thus in a conforming program we can safely assume
On Mon, Nov 7, 2011 at 11:16 AM, Richard Guenther
wrote:
> On Mon, Nov 7, 2011 at 11:07 AM, Jakub Jelinek 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
On Mon, Nov 7, 2011 at 11:07 AM, Jakub Jelinek 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
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 un
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[ Working virtually from Hawaii tonight... :-) ]
So while working on warnings for NULL pointer dereferences and seeing
how many explicit & implicit NULL pointer dereferences are left in the
statement stream due to various VEC & other oddities, I rea
30 matches
Mail list logo