This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Change the badness computation to ensure no integer-underflow
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Dehao Chen <dehao at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 28 Aug 2013 15:50:41 +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> <20130828121323 dot GB11901 at kam dot mff dot cuni dot cz>
On Wed, Aug 28, 2013 at 2:13 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Tue, Aug 27, 2013 at 2:50 PM, Jan Hubicka <hubicka@ucw.cz> 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.
Well, we care that a cross from X to T produces the same code as a cross
from Y to T or a native compiler on T. Otherwise it's hard to even think of
using icecream like we do internally.
>> 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.
Yeah, well.
Richard.
> Honza