On Tue, Feb 19, 2013 at 12:22 PM, Martin Jambor <mjam...@suse.cz> wrote: > Hi, > > On Tue, Feb 19, 2013 at 10:21:32AM +0100, Richard Biener wrote: >> On Mon, Feb 18, 2013 at 9:06 PM, Martin Jambor <mjam...@suse.cz> wrote: >> > Hi, >> > >> > after much pondering about PR 55334 I came to conclusion that no nice >> > fix to the regression could be introduced in stage4. So for the sake >> > of the SPEC 200 benchmark I decided to cripple IPA-CP on restrict >> > pointers to arrays so that the restrict-ness of the memory references >> > which need to be vectorized is not lost. >> > >> > I have tried various less aggressive tricks like only propagating the >> > one constant address that heuristics decided was profitable and not >> > all the others that came from the same calling contexts (and were >> > restrict) but then inlining came along and finished the deed with the >> > same consequences as IPA-CP had. >> > >> > That only reinforced my feeling that the patch below is a spec hack >> > and that we ought to find a better way of preserving the restrict-ness >> > across IPA optimizations. Therefore I will keep the bug open and >> > revert this patch after 4.8 is branched and stage1 opens. >> > >> > Meanwhile, this passes bootstrap and testsuite on x86_64-linux. OK >> > for trunk? >> > >> > Thanks, >> > >> > Martin >> > >> > >> > 2013-02-07 Martin Jambor <mjam...@suse.cz> >> > >> > PR tree-optimization/55334 >> > * ipa-cp.c (initialize_node_lattices): Disable IPA-CP through and >> > to >> > restricted pointers to arrays. >> > >> > Index: src/gcc/ipa-cp.c >> > =================================================================== >> > --- src.orig/gcc/ipa-cp.c >> > +++ src/gcc/ipa-cp.c >> > @@ -730,6 +730,22 @@ initialize_node_lattices (struct cgraph_ >> > cgraph_node_name (node), node->uid, >> > disable ? "BOTTOM" : "VARIABLE"); >> > } >> > + if (!disable) >> > + for (i = 0; i < ipa_get_param_count (info) ; i++) >> > + { >> > + struct ipcp_param_lattices *plats = ipa_get_parm_lattices (info, >> > i); >> > + tree t = TREE_TYPE (ipa_get_param(info, i)); >> > + >> > + if (TYPE_RESTRICT (t) && POINTER_TYPE_P (t) >> >> You want to first test for POINTER_TYPE_P and then for TYPE_RESTRICT. >> > > I see, will do. > >> > + && TREE_CODE (TREE_TYPE (t)) == ARRAY_TYPE) >> >> With only testing for ARRAY_TYPE here you will still IPA-CP array >> descriptors, right? Those are RECORD_TYPE, the parameter being >> DECL_BY_REFERENCE. > > Possibly, why do you think that matters? In reality, can the > descriptors ever be global variables and thus propagated? (This is > all about the old scalar IPA-CP, it has nothing to do with the new > aggregate one. It's just that in 4.8 heuristics decides to clone > since an otherwise unrelated patch in r190015. In fact, aggregate > IPA-CP is not disabled by this patch).
I'm not sure about global array descriptors but I seem to remember seeing those. >> So I'd try instead >> >> && DECL_BY_REFERENCE (ipa_get_parm (info, i)) >> > > This would also disable propagation of simple scalar constants passed > by reference the Fortran way (I have just checked by looking at of PR > 53787) which I specifically did not want to do. Therefore, I'd rather > stick to my original proposal (modulo the order of pointer and > restrict tests order). Ok, that makes sense. >> which leads me to the question - what is ipa_get_parm (info, i) returning? >> Is it the lattice _value_? Or is it the PARM_DECL of the callee (which is >> the only important piece of information!)? > > The PARM_DECL. Fine. The patch is ok then, with the restrict / pointer test re-ordered. Thanks, Richard. > Thanks, > > Martin