This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Change the badness computation to ensure no integer-underflow

On Tue, Aug 27, 2013 at 2:50 PM, Jan Hubicka <> 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
> afternoon.
> Honza
>> >>>
>> >>> 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);

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]