On 6/12/20 3:25 PM, Martin Jambor wrote:
> Hi,
>
> when Fortran functions pass array descriptors they receive as a
> parameter to another function, they actually rebuild it.  Thanks to
> work done mainly by Feng, IPA-CP can already handle the cases when
> they pass directly the values loaded from the original descriptor.
> Unfortunately, perhaps the most important one, stride, is first
> checked against zero and is replaced with one in that case:
>
>   _12 = *a_11(D).dim[0].stride;
>   if (_12 != 0)
>     goto <bb 4>; [50.00%]
>   else
>     goto <bb 3>; [50.00%]
>
>   <bb 3>
>     // empty BB
>   <bb 4>
>   # iftmp.22_9 = PHI <_12(2), 1(3)>
>    ...
>    parm.6.dim[0].stride = iftmp.22_9;
>    ...
>    __x_MOD_foo (&parm.6, b_31(D));
>
> in the most important and hopefully common cases, the incoming value
> is already 1 and we fail to propagate it.
>
> I would therefore like to propose the following way of encoding this
> situation in pass-through jump functions using using ASSERTT_EXPR
> operation code meaning that if the incoming value is the same as the
> "operand" in the jump function, it is passed on, otherwise the result
> is unknown.  This of course captures only the single (but most
> important) case but is an improvement and does not need enlarging the
> jump function structure and is simple to pattern match.  Encoding that
> zero needs to be changed to one would need another field and matching
> it would be slightly more complicated too.
>
> Bootstrapped and tested on x86_64-linux, LTO bootstrap is underway.  OK
> if it passes?
>
> Thanks,
>
> Martin
>
>
> 2020-06-12  Martin Jambor  <mjam...@suse.cz>
>
>       * ipa-prop.h (ipa_pass_through_data): Expand comment describing
>       operation.
>       * ipa-prop.c (analyze_agg_content_value): Detect new special case and
>       encode it as ASSERT_EXPR.
>       * ipa-cp.c (values_equal_for_ipcp_p): Move before
>       ipa_get_jf_arith_result.
>       (ipa_get_jf_arith_result): Special case ASSERT_EXPR.
>
>       testsuite/
>       * gfortran.dg/ipcp-array-2.f90: New test.
I don't see any feedback on this (old) patch.

It's not obvious from the patch, but I get the impression that the
ASSERT_EXPR isn't actually added to the IL, but instead just gets
stuffed into the agg_value structure.  Can you confirm one way or the
other.  If it ends up in the IL then we need to make sure it doesn't
escape the pass.

Assuming we don't ultimately extract the info from the agg_value
structure and add it to the IL, I don't have any significant concerns
about this patch.  Do you want to re-test it and include it in gcc-11?

jeff


Reply via email to