On Mon, Apr 29, 2019 at 8:01 PM Richard Biener
<richard.guent...@gmail.com> wrote:
>
> 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.
>
> I wonder if changing comp_cost::cost to int64_t would help instead? See also
> my
> suggestion to use gmp.
It might be too heavy using gmp, I will try to change to int64_t which
should be more than enough.
>
> 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?
Yeah, this is feasible. Only we wouldn't detect INFTY overflow in
release build using assert.
BTW, I failed to create generic test for PR90240. The manually tiled
loop nest doesn't trigger the issue as graphite does.
Thanks,
bin
>
> Thanks,
> Richard.
>
> > Thanks,
> > bin
