Hi, On Mon, Jun 15 2020, Jan Hubicka wrote: >> On Fri, Jun 12, 2020 at 11:28 PM Martin Jambor <mjam...@suse.cz> 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? >> >> Looks reasonable - I wonder if we somehow track enough info to >> infer the _12 != 0 check in IPA propagation? So whether there's the >> possibility to not use "conditional 1" as I understand you do but >> "conditional *a_11(D).dim[0].stride"? Because AFAICS you >> compare _12 against 1 in IPA propagation to enable the propagation, >> why not compare it against 0? Or even allow all cases to be resolved >> if _12 is a constant? That is, propagate a "_12 != 0 ? 12 : 1" jump >> function which you should be able to resolve in the exact same >> way via values_equal_for_ipa_cp_p?
It can of course be pattern matched. Then I can invent another special meaning for another _EXPR operation or perhaps start encoding these special operations a bit more sanely. > > I was wondering, since we can now represent more complex arithmetic > operations, if we can express param0 + (param0 != 0) using the jump > function w/o use of assert exprs? ...I don't quite understand what you think has changed recently, we still can only represent one arithmetic operation in pass-through jump functions. They still have one tree_code for the operation and one tree for the second operand of the operation, but into that one tree I can put something like (cond-expr (error_node != 0 ) error-node 1) or anything arbitrarily complex, and when evaluating it, make a copy, replace all error_nodes with the constant and attempt to fold it. But probably you meant something else? > > In general assert exprs seems like good concept to represent conditional > jumps though. OK then, I'll try to extend the matcher to also take the condition into account (for simple situation like these) and use the assert expr only when it fails. 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.
