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]

Re: Second Draft "Unsafe fp optimizations" project description.

Gabriel Dos_Reis wrote:

> Thanks for reiterating over this.
> | Optimizations that change the meaning of floating point expressions
> It would be more accurate and consistent with latter description to
> say  "Transformations" instead of "Optimizations".

Well, the reason I used the word "optimizations" here is that I agree
with Robert's point of view that there is little to gain from these
transformations if they aren't optimizations.  So I prefer to keep that

> | Why would someone forego numerical accuracy for speed ? Isn't the fast but
> | wrong answer useless ?
> |
> | Unfortunately, this simple reasoning doesn't cut it in the Real World.
> I think the above description is somehow misleading.

> What about
>   In numerical problems, there are roughly two kinds of computations:
>   1) those who need full precision in order to guarantee the results, and
>   2) those which are less sensible to occasional loss of accuracy.
>   For the latter category, it is reasaonable to forego the numerical
>   accuracy for speed.

Yep, I was in a certain mood when I wrote the above - I'll rewrite it to
something equivalent to your suggestion above.  I'll also remove the jab
at "first person shooting game" - it was funny the first time, but it
gets old real fast ...

> | Open issues
> |
> | We should come up with a classification for complex arithmetic too. Just A/B
> | with A and B complex already has a couple of different possible evaluations.
> We should also document cases where the transformations considered in
> this project depend on targets.  For example, Power does its
> floating point arithmetics in 64-bit whereas Sparc has two distinct
> categories of floating point arithmetic instructions -- a target may
> choose to use full 64-bits because it is faster (althought I doubt
> that is the case on Sparcs).

Certainly, that's a refinement we have to add later.

Toon Moene - - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77:
Join GNU Fortran 95: (under construction)

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