Hi, Richard,

Could you take a second look at this patch?

Thanks,
Dehao

On Mon, Jun 24, 2013 at 3:45 PM, Dehao Chen <de...@google.com> wrote:
> The original patch has some flaw. The new patch is attached.
> Bootstrapped and passed regression tests.
>
> Thanks,
> Dehao
>
> On Mon, Jun 24, 2013 at 9:44 AM, Dehao Chen <de...@google.com> wrote:
>> Hi, Richard,
>>
>> I've updated the patch (as attached) to use sreal to compute badness.
>>
>> Thanks,
>> Dehao
>>
>> On Mon, Jun 24, 2013 at 5:41 AM, Richard Biener
>> <richard.guent...@gmail.com> wrote:
>>> On Sat, Jun 22, 2013 at 2:59 AM, Dehao Chen <de...@google.com> wrote:
>>>> This patch prevents integer-underflow of badness computation in ipa-inline.
>>>>
>>>> Bootstrapped and passed regression tests.
>>>>
>>>> OK for trunk?
>>>>
>>>> Thanks,
>>>> Dehao
>>>>
>>>> gcc/ChangeLog:
>>>> 2013-06-21  Dehao Chen  <de...@google.com>
>>>>
>>>>         * ipa-inline.c (edge_badness): Fix integer underflow.
>>>>
>>>> Index: gcc/ipa-inline.c
>>>> ===================================================================
>>>> --- gcc/ipa-inline.c (revision 200326)
>>>> +++ gcc/ipa-inline.c (working copy)
>>>> @@ -888,11 +888,9 @@ edge_badness (struct cgraph_edge *edge, bool dump)
>>>>    else if (max_count)
>>>>      {
>>>>        int relbenefit = relative_time_benefit (callee_info, edge, 
>>>> edge_time);
>>>> -      badness =
>>>> - ((int)
>>>> - ((double) edge->count * INT_MIN / 2 / max_count /
>>>> RELATIVE_TIME_BENEFIT_RANGE) *
>>>> - relbenefit) / growth;
>>>> -
>>>> +      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.
>>>
>>> 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);

Reply via email to