[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,
> bin

More information about the Gcc-patches mailing list