-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 path.
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
-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 - probably not
-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 were
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 function call
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
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
-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 runtime.
-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
things
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/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); }
*p = 2; }
...
-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
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
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
Jeff == Jeff Law l...@redhat.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 06:53, Tom Tromey wrote:
Jeff == Jeff Law l...@redhat.com 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
On Mon, Nov 7, 2011 at 4:43 PM, Jeff Law l...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 06:53, Tom Tromey wrote:
Jeff == Jeff Law l...@redhat.com writes:
Jeff First, it's perfectly fine to have a NULL pointer dereference
in a Jeff program as long as that
Jeff == Jeff Law l...@redhat.com 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,
-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 in
On Mon, Nov 7, 2011 at 5:07 PM, Jeff Law l...@redhat.com 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
2011/11/7 Richard Guenther richard.guent...@gmail.com:
On Mon, Nov 7, 2011 at 5:07 PM, Jeff Law l...@redhat.com 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
On 11/07/2011 04:54 PM, Tom Tromey wrote:
Jeff == Jeff Lawl...@redhat.com 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
-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 l...@redhat.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 08:54, Tom Tromey wrote:
Jeff == Jeff Law l...@redhat.com 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
-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 standards
-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 a
On Mon, Nov 7, 2011 at 8:03 PM, Jeff Law l...@redhat.com 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
27 matches
Mail list logo
