On Sun, May 5, 2019 at 8:05 AM bin.cheng <bin.ch...@linux.alibaba.com> wrote:
>
> Hmm, mis-attached the old version patch. Here is the updated one.
OK (if still needed)
Richard.
> Thanks,
> bin
>
> ------------------------------------------------------------------
> Sender:bin.cheng <bin.ch...@linux.alibaba.com>
> Sent At:2019 May 5 (Sun.) 13:54
> Recipient:Richard Biener <richard.guent...@gmail.com>
> Cc:GCC Patches <gcc-patches@gcc.gnu.org>
> Subject:Re: [PATCH PR90240][RFC]Avoid scaling cost overflow by introducing
> scaling bound
>
>
> > ------------------------------------------------------------------
> > Sender:Richard Biener <richard.guent...@gmail.com>
> > Sent At:2019 Apr. 29 (Mon.) 20:01
> > Recipient:bin.cheng <bin.ch...@linux.alibaba.com>
> > Cc:GCC Patches <gcc-patches@gcc.gnu.org>; mliska <mli...@suse.cz>
> > Subject:Re: [PATCH PR90240][RFC]Avoid scaling cost overflow by introducing
> > scaling bound
> >
> >
> > On Sat, Apr 27, 2019 at 6:13 AM bin.cheng <bin.ch...@linux.alibaba.com>
> > wrote:
> > >
> > > > Hi,
> > >
> > > This is the draft patch avoiding scaling cost overflow by introducing a
> > > scaling bound
> > > in IVOPTs. For now the bound is 20, and scaling factor will be further
> > > scaled wrto
> > > this bound. For example, scaling factor like 1, 1000, 2000(max) would be
> > > scaled to
> > > 1, 10, 20 correspondingly.
> > >
> > > HI Martin, I remember you introduced comp_cost/cost_scaling to improve
> > > one case
> > > in spec2017. Unfortunately I don't have access to the benchmark now,
> > > could you help
> > > verify that if this patch has performance issue on it please? Thanks
> > >
> > > Bootstrap and test on x86_64, and this is for further comment/discussion.
> >
> > + float factor = 1.0f * bfreq / lfreq;
> > + if (adjust_factor_p)
> > + {
> > + factor *= COST_SCALING_FACTOR_BOUND;
> > + factor = factor * lfreq / max_freq;
> > + }
> > + body[i]->aux = (void *)(intptr_t)(int) factor;
> >
> > float computations on the host shouldn't be done.
> Fixed.
> >
> > I wonder if changing comp_cost::cost to int64_t would help instead? See
> > also my
> > suggestion to use gmp.
> Next patch for PR90078 changes the cost to int64_t.
> >
> > Otherwise the approach looks sane to me - can we then even assert that
> > no overflows
> > happen and thus INFTY only appears if we manually set such cost?
> Next patch for PR90078 changes to assert on cost overflow.
>
> Attachment is the updated patch. Bootstrap/test on x86_64 along with PR90078
> patch.
> Is it OK?
>
> Thanks,
> bin
> 2019-05-05 Bin Cheng <bin.ch...@linux.alibaba.com>
>
> PR tree-optimization/90240
> * tree-ssa-loop-ivopts.c (get_scaled_computation_cost_at): Scale cost
> with respect to scaling factor pre-computed for each basic block.
> (try_improve_iv_set): Return bool if best_cost equals to iv_ca cost.
> (find_optimal_iv_set_1): Free iv_ca set if it has infinite_cost.
> (COST_SCALING_FACTOR_BOUND, determine_scaling_factor): New.
> (tree_ssa_iv_optimize_loop): Call determine_scaling_factor. Extend
> live range for array of loop's basic blocks. Cleanup aux field of
> loop's basic blocks.
>
> 2018-05-05 Bin Cheng <bin.ch...@linux.alibaba.com>
>
> PR tree-optimization/90240
> * gfortran.dg/graphite/pr90240.f: New test.
