This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Change the badness computation to ensure no integer-underflow
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Dehao Chen <dehao at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 28 Aug 2013 14:13:23 +0200
- Subject: Re: [PATCH] Change the badness computation to ensure no integer-underflow
- Authentication-results: sourceware.org; auth=none
- References: <CAO2gOZX-YhBDxZmEGXztty6H+KAdbKtpPhyY5betB0tHj0dhwQ at mail dot gmail dot com> <CAFiYyc06O286hxaQOLpoa--y0BMAiJf5sMVqWCe4APf4edtO2w at mail dot gmail dot com> <CAO2gOZXaNMuMPGnUAeUmHK9_Xjj69MymB6yVEidK=Z=PicyDzA at mail dot gmail dot com> <CAO2gOZXexPV1rb9ag_Xcv2sfcgOB9Uuyah1uremcMdMu1LG2Lw at mail dot gmail dot com> <CAFiYyc2ECPttt13EupXuCRdY-9NZCMfM9fjxh1JFgOfdaeX1UQ at mail dot gmail dot com> <20130827125010 dot GB6791 at atrey dot karlin dot mff dot cuni dot cz> <CAFiYyc2DDLkpn1nwEcs6AzpmR-t2nLkTuCFnQMUEQhfRvu_X4A at mail dot gmail dot com>
> On Tue, Aug 27, 2013 at 2:50 PM, Jan Hubicka <email@example.com> wrote:
> >> >>
> >> >> I've updated the patch (as attached) to use sreal to compute badness.
> >> >>>> + badness = ((int)((double) edge->count / max_count
> >> >>>> + * relbenefit / RELATIVE_TIME_BENEFIT_RANGE * INT_MIN / 2)) / growth;
> >> >>>> +
> >> >>>
> >> >>> FP operations on the host are frowned upon if code generation depends
> >> >>> on their outcome. They all should use sreal_* as predict already does.
> >> >>> Other than that I wonder why the final division is int (so we get truncation
> >> >>> and not rounding)? That increases the effect of doing the multiply by
> >> >>> relbenefit in double.
> > Sorry, i missed this patch - I need to update my scripts marking files interesting
> > to me.
> > I originally duplicated the trick from global.c that used to do this for ages.
> > The rationale is that if you do only one FP operation, then you will not get
> > difference in between hosts doing 80bit fp (x86) and 64bit fp (others) and you
> > do the operation a lot faster than sreal does. While this is on slipperly ground,
> > controlled use of double should not imply host dependency.
> Well .. the above is clearly not "one" FP operation. Also I don't follow.
> If we can assume all hosts implement proper IEEE double math then
> of course the issue is moot. But fact is we don't (not sure if we can
We are not really consistent across all hosts either, because of HOST_WIDE_INT
differences. What we really cared about is to have compiler that does not give
different result based on build flags.
> declare such hosts broken and unsupported as host). Of couse on
> a perfect IEEE compliant host sreal.[ch] could be simply mapped to
> double. Oh, and yes, 80bit x87 unit isn't holding up to that premises.
sreal is not IEEE compliant. We first time hit the problem of doing
non-trivial chains of fp opreations in predict.c during my school project and
Josef implemented it as a dirty but resonably quick FP emulation module.
Hopefully it will work well enough in badness computationm, too.
I am giving the patch brief benchmarking on profiledbootstrap and it it won't
cause major regression, I think we should go ahead with the patch.
I was never really happy about the double use there and in fact the whole fixed
point arithmetic in badness compuation is a mess. If we had template based
fibonaci heap and sreal fast enough, turing it all to reals would save quite
some maintenance burden.