[Bug tree-optimization/67742] New: 3rd-level restrict ignored

[Bug tree-optimization/67742] New: 3rd-level restrict ignored

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67742

            Bug ID: 67742
           Summary: 3rd-level restrict ignored
           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 test-case test.c:
...
struct s
{
  int *__restrict *__restrict pp1;
  int *__restrict *__restrict pp2;
};

void
f (struct s *__restrict sp)
{
  **(sp->pp1) = 1;
  **(sp->pp2) = 2;
}
...

We current generate at ealias:
...
f (struct s * restrict spD.1758)
{
  intD.6 * restrict * _3;
  intD.6 * _4;
  intD.6 * restrict * _6;
  intD.6 * _7;

  # VUSE <.MEM_1(D)>
  # PT = { D.1768 } (nonlocal)
  _3 = MEM[(struct s *)sp_2(D) clique 1 base 1].pp1D.1756;

  # VUSE <.MEM_1(D)>
  # PT = nonlocal escaped
  _4 = MEM[(intD.6 * restrict *)_3 clique 1 base 2];

  # .MEM_5 = VDEF <.MEM_1(D)>
  *_4 = 1;

  # VUSE <.MEM_5>
  # PT = { D.1769 } (nonlocal)
  _6 = MEM[(struct s *)sp_2(D) clique 1 base 1].pp2D.1757;

  # VUSE <.MEM_5>
  # PT = nonlocal escaped
  _7 = MEM[(intD.6 * restrict *)_6 clique 1 base 3];

  # .MEM_8 = VDEF <.MEM_5>
  *_7 = 2;
...

The two stores are missing clique/base annotation.

[Bug tree-optimization/67742] 3rd-level restrict ignored

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67742

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-09-28
                 CC|                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug tree-optimization/67742] 3rd-level restrict ignored

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67742

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Confirmed.

Richard,

any ideas or hints how this can be implemented in tree-ssa-structalias.c?

Thanks,
- Tom

[Bug tree-optimization/67742] 3rd-level restrict ignored

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67742

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 28 Sep 2015, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67742
> 
> --- Comment #3 from vries at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #1)
> > Confirmed.
> 
> Richard,
> 
> any ideas or hints how this can be implemented in tree-ssa-structalias.c?

I think you'd want to refactor create_variable_info_for_1 to take
a parameter on whether restrict should be proceesed like in
intra_create_variable_infos, moving the special handling there
and instead of calling get_vi_for_tree on the PARM_DECL directly
call create_variable_info_for_1.

You'd have to record the respective pointer type in the fieldstack
for only-restrict-pointer vars (and similar things for non-aggregates).

Basically create_variable_info_for_1 (...., yes-process-restrict)
should handle arbitrary level restrict by means of recursion.

[Bug tree-optimization/67742] 3rd-level restrict ignored

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67742

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #5 from vries at gcc dot gnu.org ---
- https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02702.html
- https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02703.html
- https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02838.html