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

["bin.cheng" <bin dot cheng at linux dot alibaba dot com>]

Hmm, mis-attached the old version patch.  Here is the updated one.

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.

Attachment: 0001-pr90240.patch
Description: Binary data