This is the mail archive of the
mailing list for the GCC project.
Re: numerical instability and estimate-probability
- From: Jan Hubicka <jh at suse dot cz>
- To: Geert bosch <bosch at gnat dot com>
- Cc: mike stump <mrs at windriver dot com>, gcc-pdo at atrey dot karlin dot mff dot cuni dot cz, gcc at gcc dot gnu dot org, jh at suse dot cz, rth at cygnus dot com
- Date: Fri, 16 Nov 2001 12:52:09 +0100
- Subject: Re: numerical instability and estimate-probability
- References: <200111151931.LAA05450@kankakee.wrs.com> <E44A6D71-DA16-11D5-BDE4-00039344BF4A@gnat.com>
> On Thursday, November 15, 2001, at 02:31 , mike stump wrote:
> >One can `fix' this by doing the arithmetic in double, doing it safely,
> >and then chopping the number down to say, 5 or 10 digits at the end.
> >This way increase the odds that the numbers will be the same of all
> >platforms, and that the same code will be generated. [ crossed
> >fingers we can do without a portible math library ]
> In practice you will not achieve this. With probabilities, one
> might often end up in exact inbetween cases, where double rounding
> as is done on x86 when using double can wreak havoc. Even apart
> from the x86, it is hard to guarantee bit-identical results on
> different systems.
Actually the current code seems to produce same probabilities as on
I am rounding after each operations and the operantions are just dividing
by 10000 and summing. Perhaps if I get it dividing by ppower of 16 I get
stable result, but someone with more fp expirience can take a look.
> I think GCC should just not use floating-point arithmetic at all
> for making code generation decisions. It might be best to define
> a probability type using integers and have some functions for adding
> and multiplying them.
Yes, this is an alternative I was mentinong in the parallel post to
Bascilly the question is, do we want to jump for GMP library?
We need large arithmetics elsewhere too.
The probabilities are already integer. The estiimate-probabilities is
using floats only to compute frequencies of basic blocks. IT is done
so just because it is dificult to fit in integers for this purpose.
Imagine 10 nested loopos each predicted to iterate 10 times.
What I do is to compute frequencies in floats and then rescale them
in the range 0 to 10000 so I get accurate information in hot spots,
I am open to all suggestions.