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

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.


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