| Message ID | 56013E8C.5060703@mentor.com |
|---|---|
| State | New |
| Headers | show |
On Tue, 22 Sep 2015, Tom de Vries wrote: > Hi, > > Consider this test-case: > ... > struct ps > { > int *__restrict__ p; > }; > > f (struct ps &__restrict__ ps1) > { > *(ps1.p) = 1; > } > ... > > Atm (meaning after the fix for PR67666) for this test-case, we register two > clique/base annotations, one for the load of pointer ps1.p and one for the > store to that pointer: > ... > void f(ps&) (struct psD.2252 & restrict ps1D.2255) > { > intD.9 * _3; > > # VUSE <.MEM_1(D)> > # PT = { D.2262 } (nonlocal) > _3 = MEM[(struct psD.2252 &)ps1_2(D) clique 1 base 1].pD.2254; > > # .MEM_4 = VDEF <.MEM_1(D)> > MEM[(intD.9 *)_3 clique 1 base 2] = 1; > ... > > > If we rewrite the test-case by replacing the struct with its only field, we > get: > ... > f (int *__restrict__ &__restrict__ p) > { > *p = 1; > } > ... > > However, in this case, we register only one clique/base annotation, for the > load of pointer p, but not for the store to pointer p: > ... > void f(int* __restrict__&) (intD.9 * restrict & restrict pD.2255) > { > intD.9 * _3; > > # VUSE <.MEM_1(D)> > # PT = nonlocal escaped > _3 = MEM[(intD.9 * restrict &)p_2(D) clique 1 base 1]; > > # .MEM_4 = VDEF <.MEM_1(D)> > *_3 = 1; > ... > > > This patch makes sure we register both clique/base annotations for the the > second example. > > Bootstrapped and reg-tested on x86_64. > > OK for trunk? Ok. Thanks, Richard. > Thanks, > - Tom >
Handle restrict pointer references as restrict in AA 2015-09-22 Tom de Vries <tom@codesourcery.com> PR tree-optimization/67671 * tree-ssa-structalias.c (create_variable_info_for_1): Handle restrict pointer references as restrict. * g++.dg/pr67671.C: New test. --- gcc/testsuite/g++.dg/pr67671.C | 12 ++++++++++++ gcc/tree-ssa-structalias.c | 3 +++ 2 files changed, 15 insertions(+) create mode 100644 gcc/testsuite/g++.dg/pr67671.C diff --git a/gcc/testsuite/g++.dg/pr67671.C b/gcc/testsuite/g++.dg/pr67671.C new file mode 100644 index 0000000..952ea4f --- /dev/null +++ b/gcc/testsuite/g++.dg/pr67671.C @@ -0,0 +1,12 @@ +// { dg-do compile } +// { dg-options "-O2 -fdump-tree-ealias-all" } + +void +f (int *__restrict__ &__restrict__ p) +{ + *p = 1; +} + +// { dg-final { scan-tree-dump-times "clique 1 base 1" 1 "ealias" } } +// { dg-final { scan-tree-dump-times "clique 1 base 2" 1 "ealias" } } +// { dg-final { scan-tree-dump-times "(?n)clique .* base .*" 2 "ealias" } } diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c index b5b9d0a..0a8998c 100644 --- a/gcc/tree-ssa-structalias.c +++ b/gcc/tree-ssa-structalias.c @@ -5684,6 +5684,9 @@ create_variable_info_for_1 (tree decl, const char *name) vi->fullsize = tree_to_uhwi (declsize); vi->size = vi->fullsize; vi->is_full_var = true; + if (POINTER_TYPE_P (TREE_TYPE (decl)) + && TYPE_RESTRICT (TREE_TYPE (decl))) + vi->only_restrict_pointers = 1; fieldstack.release (); return vi; } -- 1.9.1
Hi, Consider this test-case: ... struct ps { int *__restrict__ p; }; f (struct ps &__restrict__ ps1) { *(ps1.p) = 1; } ... Atm (meaning after the fix for PR67666) for this test-case, we register two clique/base annotations, one for the load of pointer ps1.p and one for the store to that pointer: ... void f(ps&) (struct psD.2252 & restrict ps1D.2255) { intD.9 * _3; # VUSE <.MEM_1(D)> # PT = { D.2262 } (nonlocal) _3 = MEM[(struct psD.2252 &)ps1_2(D) clique 1 base 1].pD.2254; # .MEM_4 = VDEF <.MEM_1(D)> MEM[(intD.9 *)_3 clique 1 base 2] = 1; ... If we rewrite the test-case by replacing the struct with its only field, we get: ... f (int *__restrict__ &__restrict__ p) { *p = 1; } ... However, in this case, we register only one clique/base annotation, for the load of pointer p, but not for the store to pointer p: ... void f(int* __restrict__&) (intD.9 * restrict & restrict pD.2255) { intD.9 * _3; # VUSE <.MEM_1(D)> # PT = nonlocal escaped _3 = MEM[(intD.9 * restrict &)p_2(D) clique 1 base 1]; # .MEM_4 = VDEF <.MEM_1(D)> *_3 = 1; ... This patch makes sure we register both clique/base annotations for the the second example. Bootstrapped and reg-tested on x86_64. OK for trunk? Thanks, - Tom