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: 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 12:45:52 +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>
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
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.
> Badness computation is on hot the path of inliner that is the slowest WPA
> optimization we have (well becuase it only does something realy useful). I
> suppose I can try to get Martin to benchmark the patch on firefox on the
>> >>> Richard.
>> >>>> /* Be sure that insanity of the profile won't lead to increasing counts
>> >>>> in the scalling and thus to overflow in the computation above. */
>> >>>> gcc_assert (max_count >= edge->count);