Re: Expand oacc kernels after pass_fre
On 22/04/15 09:36, Richard Biener wrote: On Tue, 21 Apr 2015, Thomas Schwinge wrote: Hi! On Tue, 25 Nov 2014 12:22:02 +0100, Tom de Vries wrote: On 24-11-14 11:56, Tom de Vries wrote: On 15-11-14 18:19, Tom de Vries wrote: On 15-11-14 13:14, Tom de Vries wrote: I'm submitting a patch series with initial support for the oacc kernels directive. The patch series uses pass_parallelize_loops to implement parallelization of loops in the oacc kernels region. The patch series consists of these 8 patches: ... 1 Expand oacc kernels after pass_build_ealias 2 Add pass_oacc_kernels 3 Add pass_ch_oacc_kernels to pass_oacc_kernels 4 Add pass_tree_loop_{init,done} to pass_oacc_kernels 5 Add pass_loop_im to pass_oacc_kernels 6 Add pass_ccp to pass_oacc_kernels 7 Add pass_parloops_oacc_kernels to pass_oacc_kernels 8 Do simple omp lowering for no address taken var ... This patch moves omp expansion of the oacc kernels directive to after pass_build_ealias. The rationale is that in order to use pass_parallelize_loops for analysis and transformation of an oacc kernels region, we postpone omp expansion of that region until the earliest point in the pass list where enough information is availabe to run pass_parallelize_loops, in other words, after pass_build_ealias. The patch postpones expansion in expand_omp, and ensures expansion by adding pass_expand_omp_ssa: - after pass_build_ealias, and - after pass_all_early_optimizations for the case we're not optimizing. In order to make sure the oacc kernels region arrives at pass_expand_omp_ssa, the way it left expand_omp, the patch makes pass_ccp and pass_forwprop aware of lowered omp code, to handle it conservatively. The patch contains changes in expand_omp_target to deal with ssa-code, similar to what is already present in expand_omp_taskreg. Furthermore, the patch forces the .omp_data_sizes and .omp_data_kinds to not be static for oacc kernels. It does this to get some references to .omp_data_sizes and .omp_data_kinds in the ssa code. Without these references, the definitions will be removed. The reference of the variables in GIMPLE_OACC_KERNELS is not enough to have them not removed. [ In vries/oacc-kernels, I used a BUILT_IN_USE kludge for this purpose ]. Finally, at the end of pass_expand_omp_ssa we're left with SSA_NAMEs in the original function of which the definition has been removed (as in moved to the split off function). TODO_remove_unused_locals takes care of some of them, but not the anonymous ones. So the patch iterates over all SSA_NAMEs to find these dangling SSA_NAMEs and releases them. Reposting with small update: I've replaced the use of the rather generic gimple_stmt_omp_lowering_p with the more specific gimple_stmt_omp_data_i_init_p. Bootstrapped and reg-tested in the same way as before. I've moved pass_expand_omp_ssa one down in the pass list, past pass_fre. This allows fre to unify references to the same omp variable before entering pass_oacc_kernels, which helps pass_lim in pass_oacc_kernels. F.i. this reduction fragment: ... # VUSE <.MEM_8> # PT = { D.2282 } _67 = .omp_data_i_59->sumD.2270; # VUSE <.MEM_8> _68 = *_67; _70 = _66 + _68; # VUSE <.MEM_8> # PT = { D.2282 } _69 = .omp_data_i_59->sumD.2270; # .MEM_71 = VDEF <.MEM_8> *_69 = _70; ... is transformed by fre into: ... # VUSE <.MEM_8> # PT = { D.2282 } _67 = .omp_data_i_59->sumD.2270; # VUSE <.MEM_8> _68 = *_67; _70 = _66 + _68; # .MEM_71 = VDEF <.MEM_8> *_67 = _70; ... In order for pass_fre to respect the kernels region boundaries, I've added a change in tree-ssa-sccvn.c:visit_use to handle the .omp_data_i init conservatively. Bootstrapped and reg-tested as before. OK for trunk? Committed to gomp-4_0-branch in r79: commit 93557ac5e30c26ee1a3d1255e31265b287171a0d Author: tschwinge Date: Tue Apr 21 19:37:19 2015 + Expand oacc kernels after pass_fre gcc/ * omp-low.c: Include gimple-pretty-print.h. (release_first_vuse_in_edge_dest): New function. (expand_omp_target): When not in ssa, don't split off oacc kernels region, clear PROP_gimple_eomp in cfun->curr_properties to force later expanssion, and add GOACC_kernels_internal call. When in ssa, split off oacc kernels and convert GOACC_kernels_internal into GOACC_kernels call. Handle ssa-code. (pass_data_expand_omp): Don't set PROP_gimple_eomp unconditionally in properties_provided field. (pass_expand_omp::execute): Set PROP_gimple_eomp in cfun->curr_properties tentatively. (pass_data_expand_omp_ssa): Add TODO_remove_unused_locals to todo_flags_finish field. (pass_expand_omp_ssa::execute): Release dangling SSA_NAMEs after calling execute_expand_omp
Re: Expand oacc kernels after pass_fre
On Thu, 4 Jun 2015, Tom de Vries wrote: > > > { > > > gsi_next (&gsi); > > > continue; > > > diff --git gcc/tree-ssa-sccvn.c gcc/tree-ssa-sccvn.c > > > index e417a15..449a615 100644 > > > --- gcc/tree-ssa-sccvn.c > > > +++ gcc/tree-ssa-sccvn.c > > > @@ -85,6 +85,7 @@ along with GCC; see the file COPYING3. If not see > > > #include "ipa-ref.h" > > > #include "plugin-api.h" > > > #include "cgraph.h" > > > +#include "omp-low.h" > > > > > > /* This algorithm is based on the SCC algorithm presented by Keith > > > Cooper and L. Taylor Simpson in "SCC-Based Value numbering" > > > @@ -3542,7 +3543,8 @@ visit_use (tree use) > > > { > > > if (gimple_code (stmt) == GIMPLE_PHI) > > > changed = visit_phi (stmt); > > > - else if (gimple_has_volatile_ops (stmt)) > > > + else if (gimple_has_volatile_ops (stmt) > > > +|| gimple_stmt_omp_data_i_init_p (stmt)) > > > > No. > > > > What is the intent of these changes? > > > > These are changes to handle the kernels region conservatively, in order to not > undo the omp-lowering before getting to the oacc-parloops pass. Still it feels too much like the MPX mistake (maintainance cost and compile-time cost). How can any pass "undo" omp-lowering? Richard.
Re: Expand oacc kernels after pass_fre
On 08/06/15 09:25, Richard Biener wrote: On Thu, 4 Jun 2015, Tom de Vries wrote: { gsi_next (&gsi); continue; diff --git gcc/tree-ssa-sccvn.c gcc/tree-ssa-sccvn.c index e417a15..449a615 100644 --- gcc/tree-ssa-sccvn.c +++ gcc/tree-ssa-sccvn.c @@ -85,6 +85,7 @@ along with GCC; see the file COPYING3. If not see #include "ipa-ref.h" #include "plugin-api.h" #include "cgraph.h" +#include "omp-low.h" /* This algorithm is based on the SCC algorithm presented by Keith Cooper and L. Taylor Simpson in "SCC-Based Value numbering" @@ -3542,7 +3543,8 @@ visit_use (tree use) { if (gimple_code (stmt) == GIMPLE_PHI) changed = visit_phi (stmt); - else if (gimple_has_volatile_ops (stmt)) + else if (gimple_has_volatile_ops (stmt) + || gimple_stmt_omp_data_i_init_p (stmt)) No. What is the intent of these changes? These are changes to handle the kernels region conservatively, in order to not undo the omp-lowering before getting to the oacc-parloops pass. Still it feels too much like the MPX mistake (maintainance cost and compile-time cost). How can any pass "undo" omp-lowering? I'm talking about the rewriting of the variables in terms of .omp_data_i. Passes like copy_prop and fre undo this rewriting, and propagate the variables from outside the kernels region back into the kernels region, eliminating .omp_data_i. Thanks, - Tom
Expand oacc kernels after pass_fre (was: [PATCH, 1/8] Expand oacc kernels after pass_build_ealias)
Hi! On Tue, 25 Nov 2014 12:22:02 +0100, Tom de Vries wrote: > On 24-11-14 11:56, Tom de Vries wrote: > > On 15-11-14 18:19, Tom de Vries wrote: > >> On 15-11-14 13:14, Tom de Vries wrote: > >>> I'm submitting a patch series with initial support for the oacc kernels > >>> directive. > >>> > >>> The patch series uses pass_parallelize_loops to implement parallelization > >>> of > >>> loops in the oacc kernels region. > >>> > >>> The patch series consists of these 8 patches: > >>> ... > >>> 1 Expand oacc kernels after pass_build_ealias > >>> 2 Add pass_oacc_kernels > >>> 3 Add pass_ch_oacc_kernels to pass_oacc_kernels > >>> 4 Add pass_tree_loop_{init,done} to pass_oacc_kernels > >>> 5 Add pass_loop_im to pass_oacc_kernels > >>> 6 Add pass_ccp to pass_oacc_kernels > >>> 7 Add pass_parloops_oacc_kernels to pass_oacc_kernels > >>> 8 Do simple omp lowering for no address taken var > >>> ... > >> > >> This patch moves omp expansion of the oacc kernels directive to after > >> pass_build_ealias. > >> > >> The rationale is that in order to use pass_parallelize_loops for analysis > >> and > >> transformation of an oacc kernels region, we postpone omp expansion of that > >> region until the earliest point in the pass list where enough information > >> is > >> availabe to run pass_parallelize_loops, in other words, after > >> pass_build_ealias. > >> > >> The patch postpones expansion in expand_omp, and ensures expansion by > >> adding > >> pass_expand_omp_ssa: > >> - after pass_build_ealias, and > >> - after pass_all_early_optimizations for the case we're not optimizing. > >> > >> In order to make sure the oacc kernels region arrives at > >> pass_expand_omp_ssa, > >> the way it left expand_omp, the patch makes pass_ccp and pass_forwprop > >> aware of > >> lowered omp code, to handle it conservatively. > >> > >> The patch contains changes in expand_omp_target to deal with ssa-code, > >> similar > >> to what is already present in expand_omp_taskreg. > >> > >> Furthermore, the patch forces the .omp_data_sizes and .omp_data_kinds to > >> not be > >> static for oacc kernels. It does this to get some references to > >> .omp_data_sizes > >> and .omp_data_kinds in the ssa code. Without these references, the > >> definitions > >> will be removed. The reference of the variables in GIMPLE_OACC_KERNELS is > >> not > >> enough to have them not removed. [ In vries/oacc-kernels, I used a > >> BUILT_IN_USE > >> kludge for this purpose ]. > >> > >> Finally, at the end of pass_expand_omp_ssa we're left with SSA_NAMEs in the > >> original function of which the definition has been removed (as in moved to > >> the > >> split off function). TODO_remove_unused_locals takes care of some of them, > >> but > >> not the anonymous ones. So the patch iterates over all SSA_NAMEs to find > >> these > >> dangling SSA_NAMEs and releases them. > >> > > > > Reposting with small update: I've replaced the use of the rather generic > > gimple_stmt_omp_lowering_p with the more specific > > gimple_stmt_omp_data_i_init_p. > > > > Bootstrapped and reg-tested in the same way as before. > > > > I've moved pass_expand_omp_ssa one down in the pass list, past pass_fre. > > This allows fre to unify references to the same omp variable before entering > pass_oacc_kernels, which helps pass_lim in pass_oacc_kernels. > > F.i. this reduction fragment: > ... ># VUSE <.MEM_8> ># PT = { D.2282 } >_67 = .omp_data_i_59->sumD.2270; ># VUSE <.MEM_8> >_68 = *_67; > >_70 = _66 + _68; > ># VUSE <.MEM_8> ># PT = { D.2282 } >_69 = .omp_data_i_59->sumD.2270; ># .MEM_71 = VDEF <.MEM_8> >*_69 = _70; > ... > > is transformed by fre into: > ... ># VUSE <.MEM_8> ># PT = { D.2282 } >_67 = .omp_data_i_59->sumD.2270; ># VUSE <.MEM_8> >_68 = *_67; > >_70 = _66 + _68; > ># .MEM_71 = VDEF <.MEM_8> >*_67 = _70; > ... > > In order for pass_fre to respect the kernels region boundaries, I've added a > change in tree-ssa-sccvn.c:visit_use to hand
Re: Expand oacc kernels after pass_fre (was: [PATCH, 1/8] Expand oacc kernels after pass_build_ealias)
On Tue, 21 Apr 2015, Thomas Schwinge wrote: > Hi! > > On Tue, 25 Nov 2014 12:22:02 +0100, Tom de Vries > wrote: > > On 24-11-14 11:56, Tom de Vries wrote: > > > On 15-11-14 18:19, Tom de Vries wrote: > > >> On 15-11-14 13:14, Tom de Vries wrote: > > >>> I'm submitting a patch series with initial support for the oacc kernels > > >>> directive. > > >>> > > >>> The patch series uses pass_parallelize_loops to implement > > >>> parallelization of > > >>> loops in the oacc kernels region. > > >>> > > >>> The patch series consists of these 8 patches: > > >>> ... > > >>> 1 Expand oacc kernels after pass_build_ealias > > >>> 2 Add pass_oacc_kernels > > >>> 3 Add pass_ch_oacc_kernels to pass_oacc_kernels > > >>> 4 Add pass_tree_loop_{init,done} to pass_oacc_kernels > > >>> 5 Add pass_loop_im to pass_oacc_kernels > > >>> 6 Add pass_ccp to pass_oacc_kernels > > >>> 7 Add pass_parloops_oacc_kernels to pass_oacc_kernels > > >>> 8 Do simple omp lowering for no address taken var > > >>> ... > > >> > > >> This patch moves omp expansion of the oacc kernels directive to after > > >> pass_build_ealias. > > >> > > >> The rationale is that in order to use pass_parallelize_loops for > > >> analysis and > > >> transformation of an oacc kernels region, we postpone omp expansion of > > >> that > > >> region until the earliest point in the pass list where enough > > >> information is > > >> availabe to run pass_parallelize_loops, in other words, after > > >> pass_build_ealias. > > >> > > >> The patch postpones expansion in expand_omp, and ensures expansion by > > >> adding > > >> pass_expand_omp_ssa: > > >> - after pass_build_ealias, and > > >> - after pass_all_early_optimizations for the case we're not optimizing. > > >> > > >> In order to make sure the oacc kernels region arrives at > > >> pass_expand_omp_ssa, > > >> the way it left expand_omp, the patch makes pass_ccp and pass_forwprop > > >> aware of > > >> lowered omp code, to handle it conservatively. > > >> > > >> The patch contains changes in expand_omp_target to deal with ssa-code, > > >> similar > > >> to what is already present in expand_omp_taskreg. > > >> > > >> Furthermore, the patch forces the .omp_data_sizes and .omp_data_kinds to > > >> not be > > >> static for oacc kernels. It does this to get some references to > > >> .omp_data_sizes > > >> and .omp_data_kinds in the ssa code. Without these references, the > > >> definitions > > >> will be removed. The reference of the variables in GIMPLE_OACC_KERNELS > > >> is not > > >> enough to have them not removed. [ In vries/oacc-kernels, I used a > > >> BUILT_IN_USE > > >> kludge for this purpose ]. > > >> > > >> Finally, at the end of pass_expand_omp_ssa we're left with SSA_NAMEs in > > >> the > > >> original function of which the definition has been removed (as in moved > > >> to the > > >> split off function). TODO_remove_unused_locals takes care of some of > > >> them, but > > >> not the anonymous ones. So the patch iterates over all SSA_NAMEs to find > > >> these > > >> dangling SSA_NAMEs and releases them. > > >> > > > > > > Reposting with small update: I've replaced the use of the rather generic > > > gimple_stmt_omp_lowering_p with the more specific > > > gimple_stmt_omp_data_i_init_p. > > > > > > Bootstrapped and reg-tested in the same way as before. > > > > > > > I've moved pass_expand_omp_ssa one down in the pass list, past pass_fre. > > > > This allows fre to unify references to the same omp variable before > > entering > > pass_oacc_kernels, which helps pass_lim in pass_oacc_kernels. > > > > F.i. this reduction fragment: > > ... > ># VUSE <.MEM_8> > ># PT = { D.2282 } > >_67 = .omp_data_i_59->sumD.2270; > ># VUSE <.MEM_8> > >_68 = *_67; > > > >_70 = _66 + _68; > > > ># VUSE <.MEM_8>