On Thu, 29 Oct 2015, Tom de Vries wrote: > On 29/10/15 12:13, Richard Biener wrote: > > On Wed, 28 Oct 2015, Tom de Vries wrote: > > > > > >On 28/10/15 16:35, Richard Biener wrote: > > > > > >On Tue, 27 Oct 2015, Tom de Vries wrote: > > > > > > > > > > > > > >On 27/10/15 13:24, Tom de Vries wrote: > > > > > > > > > >Thinking it over a bit more, I realized the constraint > > > > > > handling started > > > > > > > > > >to be messy. I've reworked the patch series to simplify that > > > > > > first. > > > > > > > > > > > > > > > > > > > > 1 Simplify constraint handling > > > > > > > > > > 2 Rename make_restrict_var_constraints to > > > > > > > > > >make_param_constraints > > > > > > > > > > 3 Add recursion to make_param_constraints > > > > > > > > > > 4 Add handle_param parameter to > > > > > > create_variable_info_for_1 > > > > > > > > > > 5 Handle recursive restrict pointer in > > > > > > > > > >create_variable_info_for_1 > > > > > > > > > > 6 Handle restrict struct fields recursively > > > > > > > > > > > > > > > > > > > >Currently doing bootstrap and regtest on x86_64. > > > > > > > > > > > > > > > > > > > >I'll repost the patch series in reply to this message. > > > > > > > > > > > > > > > >This patch gets rid of this bit of code in > > > > > intra_create_variable_infos: > > > > > > > >... > > > > > > > > if (restrict_pointer_p) > > > > > > > > make_constraint_from_global_restrict (p, "PARM_RESTRICT"); > > > > > > > > else > > > > > > > >.. > > > > > > > > > > > > > > > >I already proposed to remove it here ( > > > > > > > >https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02426.html ) but > > > > > there is a > > > > > > > >problem with that approach: It can happen that restrict_pointer_p > > > > > is true, > > > > > > > >but > > > > > > > >p->only_restrict_pointers is false. This happens with fipa-pta, > > > > > when > > > > > > > >create_function_info_for created a varinfo for the parameter > > > > > before > > > > > > > >intra_create_variable_infos was called. > > > > > > > > > > > > > > > >The patch handles that case now by setting > > > > > p->only_restrict_pointers. > > > > > > > > > > > >Hmm, but ... restrict only has an effect in non-IPA mode. > > > > > > > >Indeed, I also realized that by now. > > > > > > > >I wrote attached patch to make that explicit and simplify fipa-pta. > > > > > > > >OK for trunk if bootstrap and reg-test succeeds? > > First, there was an error in the patch, it tested for flag_ipa_pta (so it also > affected ealias), but it was supposed to test for in_ipa mode. That is fixed > in attached version. > > > I don't see the patch simplifies anything but only removes spurious > > settings by adding IMHO redundant checks. > > Consider testcase: > ... > int __attribute__((noinline, noclone)) > foo (int *__restrict__ a, int *__restrict__ b) > { > *a = 1; > *b = 2; > } > > int __attribute__((noinline, noclone)) > bar (int *a, int *b) > { > foo (a, b); > } > ... > > The impact of this patch in the pta dump (focusing on the constraints bit) is: > ... > Generating constraints for foo (foo) > > -foo.arg0 = &PARM_NOALIAS(20) > -PARM_NOALIAS(20) = NONLOCAL > -foo.arg1 = &PARM_NOALIAS(21) > -PARM_NOALIAS(21) = NONLOCAL > +foo.arg0 = &NONLOCAL > +foo.arg1 = &NONLOCAL > ... > > That's the kind of simplifications I'm trying to achieve.
Yes, but as I said we should refactor things to avoid calling the intra constraints generation from the IPA path. Richard. > Thanks, > - Tom > > -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
