On Tue, 24 Nov 2015, Tom de Vries wrote:
> On 24/11/15 15:33, Richard Biener wrote:
> > On Tue, 24 Nov 2015, Tom de Vries wrote:
> >
> > > On 24/11/15 14:13, Richard Biener wrote:
> > > > On Tue, 24 Nov 2015, Tom de Vries wrote:
> > > >
> > > > > > On 23/11/15 11:02, Richard Biener wrote:
> > > > > > > > On Fri, 20 Nov 2015, Tom de Vries wrote:
> > > > > > > >
> > > > > > > > > > On 20/11/15 14:29, Richard Biener wrote:
> > > > > > > > > > > > I agree it's somewhat of an odd behavior but all passes
> > > > > > > > should
> > > > > > > > > > > > either be placed in a sub-pipeline with an outer
> > > > > > > > > > > > loop_optimizer_init()/finalize () call or call both
> > > > > > > > themselves.
> > > > > > > > > >
> > > > > > > > > > Hmm, but adding loop_optimizer_finalize at the end of
> > > > > > > > > > pass_lim
> > > > > > > breaks the
> > > > > > > > > > loop
> > > > > > > > > > pipeline.
> > > > > > > > > >
> > > > > > > > > > We could use the style used in pass_slp_vectorize::execute:
> > > > > > > > > > ...
> > > > > > > > > > pass_slp_vectorize::execute (function *fun)
> > > > > > > > > > {
> > > > > > > > > > basic_block bb;
> > > > > > > > > >
> > > > > > > > > > bool in_loop_pipeline = scev_initialized_p ();
> > > > > > > > > > if (!in_loop_pipeline)
> > > > > > > > > > {
> > > > > > > > > > loop_optimizer_init (LOOPS_NORMAL);
> > > > > > > > > > scev_initialize ();
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > > > if (!in_loop_pipeline)
> > > > > > > > > > {
> > > > > > > > > > scev_finalize ();
> > > > > > > > > > loop_optimizer_finalize ();
> > > > > > > > > > }
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > > > Although that doesn't strike me as particularly clean.
> > > > > > > >
> > > > > > > > At least it would be a consistent "unclean" style. So yes, the
> > > > > > > > above would work for me.
> > > > > > > >
> > > > > >
> > > > > > Reposting using the in_loop_pipeline style in pass_lim.
> > > > The tree-ssa-loop-im.c changes are ok
> > >
> > > OK, I'll commit those.
> > >
> > > > (I suppose the other changes
> > > > are in the other patch you posted as well).
> > >
> > > This ( https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02882.html ) patch
> > > contains changes related to adding pass_oacc_kernels2. Are those the
> > > "other
> > > changes" you're referring to?
> >
> > No, the other pathc adding oacc_kernels pass group to passes.def.
> >
>
> I don't understand. There 's only one patch adding oacc_kernels pass group to
> passes.def (which is the one in this thread).
>
> > Btw, at some point splitting patches too much becomes very much
> > confusing instead of helping.
>
> Would it help if I merge "Add pass_oacc_kernels" with this patch?
It would have, yes. As said, the excessive splitting just confuses
the review process. Will review in the present state anyway.
Richard.
> Thanks,
> - Tom
>
>
--
Richard Biener <rguent...@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
