This is the mail archive of the
`gcc@gcc.gnu.org`
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] |

*To*: gcc at gcc dot gnu dot org*Subject*: Re: What is acceptable for -ffast-math? A numerical viewpoint*From*: Kevin Handy <kth at srv dot net>*Date*: Mon, 06 Aug 2001 09:51:49 -0600*References*: <20010806092313.96EFBF2B78@nile.gnat.com>

dewar@gnat.com wrote: > > <<Can we please take it as given that no transformation will be applied > without something at least vaguely resembling a rational argument that > it could be an actual optimisation? > >> > > Once you allow a compiler to make transformation X, then the interaction > of transformations is often such that the idea of "rational argument" is > highly dubious. I already gave an argument showing why it is perfectly > believeable that a compiler would transform > > a / b > > into > > (a*K) / (b*K) If gcc does this transformation without knowing a lot about all of the numbers, then I'd suggust disabling it. Does it do this with integers? I'd really hope not. It would make even less sense if you allowed K to go to zero. You could then transform any division using this optimization through the steps "a/b" => "(a*K)/(b*K)" => "(a*0)/(b*0)" => "0/0". If you allow a transform like this, you would also have to allow a transform of "(a/K) / (b/K)", which is essentially the same transform (just invert the constant). Now allow K to go to 0, or to infinity. Showing a transform is broken by using an interation with a broken transform is also not helpful. You might as well argue that if "a+b" were optimized to "a*b", then "x+y/1.0" could be transformed into "x*y", therefor you can't translate "a/1.0" into "a". What if the compiler translated "(a*K) / (b*K)" into "a/b". This is a much more likely transformation the optimizer might make than the former. Problems with that transform would be more intresting and useful. > Sure, it is a somewhat unlikely combination of circumstances, but if there > is one thing that anyone who has worked on optimizing compilers knows, it is > that unlikely combinations of things do happen in ways that are often very > hard to anticipate, and optimzers are not in the business of "well this > speeds up most programs, and miscompiles others, but we can't tell you > the difference". I'd really like to know of possible problems in normal calculations, instead of those that are trying to push the FPU against its limits (where they shouldn't be using fast-math anyway). And problems with interactions in the proposed optimizations, not interactions with possible future ones that are broken by themselves. [I'm really not trying to sound nasty in this e-mail, just hoping to learn about real problems with proposed optimizations, not about broken non-proposed transformations]

**References**:

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |