[PATCH, PR 55334] Disable IPA-CP on restrict pointers to arrays

Richard Biener richard.guenther@gmail.com
Tue Feb 19 11:40:00 GMT 2013


On Tue, Feb 19, 2013 at 12:22 PM, Martin Jambor <mjambor@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 <mjambor@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  <mjambor@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



More information about the Gcc-patches mailing list