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