public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/67955] New: tree-dse does not use pointer info
@ 2015-10-13 13:57 vries at gcc dot gnu.org
2015-10-13 14:25 ` [Bug tree-optimization/67955] " rguenth at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2015-10-13 13:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955
Bug ID: 67955
Summary: tree-dse does not use pointer info
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this testcase, with dead store '*p = 1':
...
int
f ()
{
int a;
int *p = &a;
*p = 1;
a = 2;
return a;
}
...
We compile with -O2 -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre.
At dse1 we have
...
f ()
{
int * p;
int a;
int _5;
<bb 2>:
p_1 = &a;
*p_1 = 1;
a = 2;
_5 = a;
a ={v} {CLOBBER};
return _5;
}
...
So, the dead store '*p_1 = 1' has not been eliminated.
However, at ealias we already know:
...
Alias information for f
Aliased symbols
a, UID D.1757, int, is addressable
Call clobber information
ESCAPED, points-to non-local, points-to vars: { }
Flow-insensitive points-to information
p_1, points-to vars: { D.1757 }
...
So, we could use points-to info in dce.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/67955] tree-dse does not use pointer info
2015-10-13 13:57 [Bug tree-optimization/67955] New: tree-dse does not use pointer info vries at gcc dot gnu.org
@ 2015-10-13 14:25 ` rguenth at gcc dot gnu.org
2015-10-13 15:34 ` vries at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-10-13 14:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
We use "must point to" nowhere because we don't compute it ;)
The same points-to set results from
int *p = (int *)((char *)&a + 2);
or even
int *p = &a + 1;
so you can't use points-to info that way (to derive a must-alias).
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/67955] tree-dse does not use pointer info
2015-10-13 13:57 [Bug tree-optimization/67955] New: tree-dse does not use pointer info vries at gcc dot gnu.org
2015-10-13 14:25 ` [Bug tree-optimization/67955] " rguenth at gcc dot gnu.org
@ 2015-10-13 15:34 ` vries at gcc dot gnu.org
2015-10-14 7:28 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2015-10-13 15:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955
--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> The same points-to set results from
>
> int *p = (int *)((char *)&a + 2);
>
> or even
>
> int *p = &a + 1;
>
I see, I didn't realize that. But AFAICT, in both these cases, storing to *p is
illegal (if 'a' is a scalar int).
> so you can't use points-to info that way (to derive a must-alias).
I see your point related to an array object, there pointers to different array
elements would have identical points-to sets.
I wonder though: if we have a store '*p = 0', and the size of the store is the
same as the size of the pointed-to object of pointer p, can't we conclude that
pointer p points to the start of the object?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/67955] tree-dse does not use pointer info
2015-10-13 13:57 [Bug tree-optimization/67955] New: tree-dse does not use pointer info vries at gcc dot gnu.org
2015-10-13 14:25 ` [Bug tree-optimization/67955] " rguenth at gcc dot gnu.org
2015-10-13 15:34 ` vries at gcc dot gnu.org
@ 2015-10-14 7:28 ` rguenth at gcc dot gnu.org
2015-10-14 11:06 ` vries at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-10-14 7:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |alias, missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-10-14
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to vries from comment #2)
> (In reply to Richard Biener from comment #1)
> > The same points-to set results from
> >
> > int *p = (int *)((char *)&a + 2);
> >
> > or even
> >
> > int *p = &a + 1;
> >
>
> I see, I didn't realize that. But AFAICT, in both these cases, storing to *p
> is illegal (if 'a' is a scalar int).
>
> > so you can't use points-to info that way (to derive a must-alias).
>
> I see your point related to an array object, there pointers to different
> array elements would have identical points-to sets.
>
> I wonder though: if we have a store '*p = 0', and the size of the store is
> the same as the size of the pointed-to object of pointer p, can't we
> conclude that pointer p points to the start of the object?
Yes, for that special case we indeed can do that. I wonder if it's worth
doing though ;) Care to adjust stmt_kills_ref_p accordingly and instrument it
to see how many times during bootstrap this triggers?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/67955] tree-dse does not use pointer info
2015-10-13 13:57 [Bug tree-optimization/67955] New: tree-dse does not use pointer info vries at gcc dot gnu.org
` (2 preceding siblings ...)
2015-10-14 7:28 ` rguenth at gcc dot gnu.org
@ 2015-10-14 11:06 ` vries at gcc dot gnu.org
2015-10-14 12:18 ` vries at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2015-10-14 11:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955
--- Comment #4 from vries at gcc dot gnu.org ---
Created attachment 36507
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36507&action=edit
Tentative patch
(In reply to Richard Biener from comment #3)
> (In reply to vries from comment #2)
> > I wonder though: if we have a store '*p = 0', and the size of the store is
> > the same as the size of the pointed-to object of pointer p, can't we
> > conclude that pointer p points to the start of the object?
>
> Yes, for that special case we indeed can do that. I wonder if it's worth
> doing though ;)
I ran into this while working on the oacc kernels support. But indeed, I'm not
sure how useful this is going to be in general.
> Care to adjust stmt_kills_ref_p accordingly
Done in this tentative patch.
> and instrument it to see how many times during bootstrap this triggers?
For now, I'll do a bootstrap and reg-test to make sure it doesn't break
anything.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/67955] tree-dse does not use pointer info
2015-10-13 13:57 [Bug tree-optimization/67955] New: tree-dse does not use pointer info vries at gcc dot gnu.org
` (3 preceding siblings ...)
2015-10-14 11:06 ` vries at gcc dot gnu.org
@ 2015-10-14 12:18 ` vries at gcc dot gnu.org
2015-10-14 14:56 ` vries at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2015-10-14 12:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955
vries at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #36507|0 |1
is obsolete| |
--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 36508
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36508&action=edit
Updated tentative patch
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/67955] tree-dse does not use pointer info
2015-10-13 13:57 [Bug tree-optimization/67955] New: tree-dse does not use pointer info vries at gcc dot gnu.org
` (4 preceding siblings ...)
2015-10-14 12:18 ` vries at gcc dot gnu.org
@ 2015-10-14 14:56 ` vries at gcc dot gnu.org
2015-10-15 6:32 ` vries at gcc dot gnu.org
2015-10-15 6:32 ` vries at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2015-10-14 14:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955
--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to vries from comment #4)
> For now, I'll do a bootstrap and reg-test to make sure it doesn't break
> anything.
Updated tentative patch passes bootstrap and reg-test
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/67955] tree-dse does not use pointer info
2015-10-13 13:57 [Bug tree-optimization/67955] New: tree-dse does not use pointer info vries at gcc dot gnu.org
` (5 preceding siblings ...)
2015-10-14 14:56 ` vries at gcc dot gnu.org
@ 2015-10-15 6:32 ` vries at gcc dot gnu.org
2015-10-15 6:32 ` vries at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2015-10-15 6:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955
--- Comment #8 from vries at gcc dot gnu.org ---
Created attachment 36515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36515&action=edit
Reporting follow-up patch
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/67955] tree-dse does not use pointer info
2015-10-13 13:57 [Bug tree-optimization/67955] New: tree-dse does not use pointer info vries at gcc dot gnu.org
` (6 preceding siblings ...)
2015-10-15 6:32 ` vries at gcc dot gnu.org
@ 2015-10-15 6:32 ` vries at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2015-10-15 6:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955
--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> Care to adjust stmt_kills_ref_p accordingly and instrument it
> to see how many times during bootstrap this triggers?
I've done a bootstrap and reg-test with a printf for each trigger.
No hits in bootstrap. For reg-test:
+./gcc/testsuite/gcc/gcc.sum:FAIL: gcc.dg/ipa/ipa-pta-16.c (test for excess
errors)
+./gcc/testsuite/gcc/gcc.sum:FAIL: gcc.dg/ipa/ipa-pta-4.c (test for excess
errors)
+./gcc/testsuite/gcc/gcc.sum:FAIL: gcc.dg/ipa/ipa-pta-8.c (test for excess
errors)
+./gcc/testsuite/gcc/gcc.sum:FAIL: gcc.dg/torture/pr45967-3.c -O2 (test for
excess errors)
+./gcc/testsuite/gcc/gcc.sum:FAIL: gcc.dg/torture/pr45967-3.c -O2 -flto
(test for excess errors)
+./gcc/testsuite/gcc/gcc.sum:FAIL: gcc.dg/torture/pr45967-3.c -O2 -flto
-flto-partition=none (test for excess errors)
+./gcc/testsuite/gcc/gcc.sum:FAIL: gcc.dg/torture/pr45967-3.c -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
(test for excess errors)
+./gcc/testsuite/gcc/gcc.sum:FAIL: gcc.dg/torture/pr45967-3.c -O3 -g (test
for excess errors)
+./gcc/testsuite/gcc/gcc.sum:FAIL: gcc.dg/tree-ssa/alias-33.c (test for excess
errors)
+./gcc/testsuite/g++/g++.sum:FAIL: g++.dg/opt/thunk3.C -std=gnu++11 (test for
excess errors)
+./gcc/testsuite/g++/g++.sum:FAIL: g++.dg/opt/thunk3.C -std=gnu++14 (test for
excess errors)
+./gcc/testsuite/g++/g++.sum:FAIL: g++.dg/opt/thunk3.C -std=gnu++98 (test for
excess errors)
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-10-15 6:32 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-13 13:57 [Bug tree-optimization/67955] New: tree-dse does not use pointer info vries at gcc dot gnu.org
2015-10-13 14:25 ` [Bug tree-optimization/67955] " rguenth at gcc dot gnu.org
2015-10-13 15:34 ` vries at gcc dot gnu.org
2015-10-14 7:28 ` rguenth at gcc dot gnu.org
2015-10-14 11:06 ` vries at gcc dot gnu.org
2015-10-14 12:18 ` vries at gcc dot gnu.org
2015-10-14 14:56 ` vries at gcc dot gnu.org
2015-10-15 6:32 ` vries at gcc dot gnu.org
2015-10-15 6:32 ` vries at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).