| Message ID | 55884D11.30300@mentor.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Jun 22, 2015 at 7:59 PM, Tom de Vries <Tom_deVries@mentor.com> wrote: > Hi, > > the gomp-4_0-branch contains the kernels oacc pass group. I've run into > trouble before with this pass group due to the fact that it uses passes in > an unusual location or order (pass_lim before pass_stdarg, > https://gcc.gnu.org/ml/gcc/2015-01/msg00282.html ). > > In an attempt to find this sort of issue pro-actively, I've modified the > pass list in the following way (similar to the oacc kernels pass group, but > always functional, not just for functions with kernel regions or loops in > kernels regions), and bootstrapped and reg-tested on x86_64 on top of > gomp-4_-0-branch: > ... > NEXT_PASS (pass_build_ealias); > NEXT_PASS (pass_fre); > + NEXT_PASS (pass_ch); > + NEXT_PASS (pass_tree_loop_init); > + NEXT_PASS (pass_lim); > + NEXT_PASS (pass_tree_loop_done); > + NEXT_PASS (pass_fre); > + NEXT_PASS (pass_tree_loop_init); > + NEXT_PASS (pass_scev_cprop); > + NEXT_PASS (pass_parallelize_loops); > + NEXT_PASS (pass_expand_omp_ssa); > + NEXT_PASS (pass_tree_loop_done); > NEXT_PASS (pass_merge_phi); > NEXT_PASS (pass_dse); > ... > > Apart from running into PR66616, I found two issues with the parloops pass: > 1. handling of loop header phi, when there's no corresponding loop exit > phi (unused reduction result) > 2. handling of loop exit phi, when there's no corresponding loop header > phi (value not modified in loop) > > The two attached patches fix these problems. > > Bootstrapped and reg-tested on x864_64 on top of gomp-4_0-branch in > combination with the patch series that triggered the problem. > > Bootstrapped and reg-tested on x864_64 on top of trunk. > > OK for trunk? Ok. Thanks, Richard. > Thanks, > - Tom
Handle exit phi without header phi in create_parallel_loop 2015-06-22 Tom de Vries <tom@codesourcery.com> * tree-parloops.c (create_parallel_loop): Handle case that exit phi does not have a corresponding loop header phi. --- gcc/tree-parloops.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c index 7123c27..0693b9e 100644 --- a/gcc/tree-parloops.c +++ b/gcc/tree-parloops.c @@ -2061,13 +2061,17 @@ create_parallel_loop (struct loop *loop, tree loop_fn, tree data, !gsi_end_p (gpi); gsi_next (&gpi)) { source_location locus; - tree def; gphi *phi = gpi.phi (); - gphi *stmt; + tree def = PHI_ARG_DEF_FROM_EDGE (phi, exit); + gimple def_stmt = SSA_NAME_DEF_STMT (def); - stmt = as_a <gphi *> ( - SSA_NAME_DEF_STMT (PHI_ARG_DEF_FROM_EDGE (phi, exit))); + /* If the exit phi is not connected to a header phi in the same loop, this + value is not modified in the loop, and we're done with this phi. */ + if (!(gimple_code (def_stmt) == GIMPLE_PHI + && gimple_bb (def_stmt) == loop->header)) + continue; + gphi *stmt = as_a <gphi *> (def_stmt); def = PHI_ARG_DEF_FROM_EDGE (stmt, loop_preheader_edge (loop)); locus = gimple_phi_arg_location_from_edge (stmt, loop_preheader_edge (loop)); -- 1.9.1
Hi, the gomp-4_0-branch contains the kernels oacc pass group. I've run into trouble before with this pass group due to the fact that it uses passes in an unusual location or order (pass_lim before pass_stdarg, https://gcc.gnu.org/ml/gcc/2015-01/msg00282.html ). In an attempt to find this sort of issue pro-actively, I've modified the pass list in the following way (similar to the oacc kernels pass group, but always functional, not just for functions with kernel regions or loops in kernels regions), and bootstrapped and reg-tested on x86_64 on top of gomp-4_-0-branch: ... NEXT_PASS (pass_build_ealias); NEXT_PASS (pass_fre); + NEXT_PASS (pass_ch); + NEXT_PASS (pass_tree_loop_init); + NEXT_PASS (pass_lim); + NEXT_PASS (pass_tree_loop_done); + NEXT_PASS (pass_fre); + NEXT_PASS (pass_tree_loop_init); + NEXT_PASS (pass_scev_cprop); + NEXT_PASS (pass_parallelize_loops); + NEXT_PASS (pass_expand_omp_ssa); + NEXT_PASS (pass_tree_loop_done); NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_dse); ... Apart from running into PR66616, I found two issues with the parloops pass: 1. handling of loop header phi, when there's no corresponding loop exit phi (unused reduction result) 2. handling of loop exit phi, when there's no corresponding loop header phi (value not modified in loop) The two attached patches fix these problems. Bootstrapped and reg-tested on x864_64 on top of gomp-4_0-branch in combination with the patch series that triggered the problem. Bootstrapped and reg-tested on x864_64 on top of trunk. OK for trunk? Thanks, - Tom