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

Richard Biener richard.guenther@gmail.com
Mon Apr 29 12:13:00 GMT 2019


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.

I wonder if changing comp_cost::cost to int64_t would help instead?  See also my
suggestion to use gmp.

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?

Thanks,
Richard.

> Thanks,
> bin



More information about the Gcc-patches mailing list