On Tue, Apr 30, 2019 at 4:05 AM Bin.Cheng <amker.ch...@gmail.com> wrote:
>
> 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.
It probably requires a GIMPLE testcase with appropriate basic block counts
(GIMPLE FE support for that coming).
Richard.
> Thanks,
> bin
> >
> > Thanks,
> > Richard.
> >
> > > Thanks,
> > > bin
