From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tim Prince" To: "Jan Hubicka" Cc: "Jan Hubicka" , "Toon Moene" , "Joern Rennecke" , Subject: Re: What is acceptable for -ffast-math? (Was: associative law in combine) Date: Sun, 29 Jul 2001 10:18:00 -0000 Message-id: <005d01c11852$bf3597f0$9865fea9@timayum4srqln4> References: <200107172259.f6HMxYU31134@phal.cambridge.redhat.com> <3B55427F.4790646A@moene.indiv.nluug.nl> <20010718104420.E29584@atrey.karlin.mff.cuni.cz> <004501c117f4$84a48c80$9865fea9@timayum4srqln4> <20010729153107.C3548@atrey.karlin.mff.cuni.cz> X-SW-Source: 2001-07/msg01867.html ----- Original Message ----- From: "Jan Hubicka" To: "Tim Prince" Cc: "Jan Hubicka" ; "Toon Moene" ; "Joern Rennecke" ; Sent: Sunday, July 29, 2001 6:31 AM Subject: Re: What is acceptable for -ffast-math? (Was: associative law in combine) > > > > This optimization is specifically permitted for appropriate data types > > by the Fortran standard, with the reservation that parentheses employed > > to prevent re-association must be observed. As gcc is unable to > > distinguish between the expressions (a/b)/c and a/b/c, this optimization > > would violate the standard in the former case, so is undesirable for > > enabling under -ffast-math. > Our documentation of -ffast-math seems to be wondefully incomplette: > > This option causes the preprocessor macro @code{__FAST_MATH__} to be defined. > > This option should never be turned on by any @option{-O} option since > it can result in incorrect output for programs which depend on > an exact implementation of IEEE or ISO rules/specifications for > math functions. > > But my understanding is, that -ffast-math allow compiler to do transformations > not strictly correct, but working in was majority of cases. The > transofrmations mentioned above looks like good example of these. > > I would like to keep them under -ffast-math for simple purpose, that users > tends to know about -ffast-math and use it, but don't know about possibly new > functions. I believe that the typical usage of Joe user will be to try > "-ffast-math" and if don't work and he is really interested in the > perofrmance, he will try the suboptions. > > GLIBC for instance does inlining of some math functions on -ffast-math that > gives inexact results. Thanks for bringing this up. This is an example of inflicting too many dangerous shortcuts under one option; worse, an option which kicks in by default already at -O, in violation of the rule you quoted above. I myself use a saner version of . It allows gcc-3.1 to out-perform g77, without all those crashes on exceptional arguments. (OT) I don't see the decisions about options made by gcc having much influence on glibc, nor should the decisions made for glibc influence gcc when they don't make sense. I see a need now for some changes in math library support for P4, but the level of interest may be insufficient. > > I agree with idea of adding new options to control this feature, but as > options of -ffast-math, as the -funsafe-math-optimizations, -ftrapping-math > and -ferrno-math is currently implemented. This seems OK if we have a documented way to turn off individually the sub-options of -ffast-math. I have been experimenting this morning with -ffast-math and trying to over-ride the individual options. I think it works, but -march=pentiumpro -ffast-math has lost its good effect for P-III in g77-3.1 now that short IF blocks are producing jumps out of line. gcc has not picked up this behavior, but I see now that -ffast-math is no longer required to obtain efficient code for floating point compare and branch. > > > > When Honza and I first discussed this, and also the transformation > > > > for(i=0;i > a[i]=b[i]/c; > > > > to > > > > for(i=0;i > a[i]=b[i]*(1/c); > I've already implemented this transformation. > > > > I mentioned that these would put too many risks in the -ffast-math > > category. I would like to see -ffast-math permit only those > > optimizations outside of IEEE compliance which are generally expected > > (e.g. according to Fortran standard). > You do have experience with this options. Do you know examples of programs > where it fails? The pre-inversion may make noticeable differences in accuracy, and those may well be of concern. It shouldn't fail on an IEEE-compliant architecture, in the normal course of events. As others pointed out, the re-association of division makes opportunities for changes in over- and under-flow behavior, from which IA32 architectures will no longer be protected, with the increasing use of SSE instructions. In a large application, if something breaks when turning on a family of unsafe optimizations, when there is no documented way of turning them on individually, the only practical solution may be to do without the optimizations. I have spent weeks on a binary search to find out which methods in a C++ application were breaking with optimization, on a platform for which g++ is not available. > > For instance we already do reassociation with -ffast-math > > > > For gcc-3.1, I would like to see an additional switch to permit > > optimizations such as the ones on floating point division mentioned > > above. I don't care about the name, but it should be more mnemonic than > > the ones used by commercial compilers; something like -ffast-div. > This sounds resonable name. If no one complains, I will add it in the > sense mentioned above. > > Honza