On Mon, Jun 22, 2015 at 7:59 PM, Tom de Vries <tom_devr...@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
