[PATCH PR90240][RFC]Avoid scaling cost overflow by introducing scaling bound

[Richard Biener]

On Sun, May 5, 2019 at 8:05 AM bin.cheng <bin.cheng@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.cheng@linux.alibaba.com>
> Sent At:2019 May 5 (Sun.) 13:54
> Recipient:Richard Biener <richard.guenther@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.guenther@gmail.com>
> > Sent At:2019 Apr. 29 (Mon.) 20:01
> > Recipient:bin.cheng <bin.cheng@linux.alibaba.com>
> > Cc:GCC Patches <gcc-patches@gcc.gnu.org>; mliska <mliska@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.cheng@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.cheng@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.cheng@linux.alibaba.com>
>
>         PR tree-optimization/90240
>         * gfortran.dg/graphite/pr90240.f: New test.