[Bug tree-optimization/67955] New: tree-dse does not use pointer info

[Bug tree-optimization/67955] New: tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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.

[Bug tree-optimization/67955] tree-dse does not use pointer info

[rguenth at gcc dot gnu.org]

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).

[Bug tree-optimization/67955] tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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?

[Bug tree-optimization/67955] tree-dse does not use pointer info

[rguenth at gcc dot gnu.org]

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?

[Bug tree-optimization/67955] tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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.

[Bug tree-optimization/67955] tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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

[Bug tree-optimization/67955] tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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

[Bug tree-optimization/67955] tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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

[Bug tree-optimization/67955] tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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)