* Re: associative law in combine [not found] ` <3B548FAA.E174E765@moene.indiv.nluug.nl> @ 2001-07-17 12:23 ` Jan Hubicka 2001-07-17 15:41 ` Dima Volodin 2001-07-17 15:59 ` Joern Rennecke 0 siblings, 2 replies; 13+ messages in thread From: Jan Hubicka @ 2001-07-17 12:23 UTC (permalink / raw) To: Toon Moene, gcc > Jan Hubicka wrote: > > > > Sure, but not in fold-CONST.c :-) > > OK, what is the apropriate place for that then? We simply need it to be done > > at tree level. It is FOLD-const after all :) > > Unfortunately, I don't know. > > Perhaps just asking it on the list is best. OK, so to speak loud - where is the proper place to convert a/b/c to a/(b*c) at tree level. fold-const or some other? Honza ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: associative law in combine 2001-07-17 12:23 ` associative law in combine Jan Hubicka @ 2001-07-17 15:41 ` Dima Volodin 2001-07-17 15:59 ` Joern Rennecke 1 sibling, 0 replies; 13+ messages in thread From: Dima Volodin @ 2001-07-17 15:41 UTC (permalink / raw) To: Jan Hubicka; +Cc: Toon Moene, gcc On Tue, 17 Jul 2001 21:21:25 +0200, you wrote: >> Jan Hubicka wrote: >> >> > > Sure, but not in fold-CONST.c :-) >> > OK, what is the apropriate place for that then? We simply need it to be done >> > at tree level. It is FOLD-const after all :) >> >> Unfortunately, I don't know. >> >> Perhaps just asking it on the list is best. >OK, so to speak loud - where is the proper place to convert >a/b/c to a/(b*c) at tree level. fold-const or some other? Are you sure you want to do that at all? These two expressions have different overflow properties and might produce different results. >Honza Dima ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: associative law in combine 2001-07-17 12:23 ` associative law in combine Jan Hubicka 2001-07-17 15:41 ` Dima Volodin @ 2001-07-17 15:59 ` Joern Rennecke 2001-07-18 1:01 ` Toon Moene 1 sibling, 1 reply; 13+ messages in thread From: Joern Rennecke @ 2001-07-17 15:59 UTC (permalink / raw) To: Jan Hubicka; +Cc: Toon Moene, gcc > > > Jan Hubicka wrote: > > > > > > Sure, but not in fold-CONST.c :-) > > > OK, what is the apropriate place for that then? We simply need it to be done > > > at tree level. It is FOLD-const after all :) > > > > Unfortunately, I don't know. > > > > Perhaps just asking it on the list is best. > OK, so to speak loud - where is the proper place to convert > a/b/c to a/(b*c) at tree level. fold-const or some other? Only if b and c are constants, the operations are floating point, and b can be multiplied with c without loss of precision or overflow. Or if b and/or c is a power of two, and b can be multiplied with c without overflow. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: associative law in combine 2001-07-17 15:59 ` Joern Rennecke @ 2001-07-18 1:01 ` Toon Moene 2001-07-18 1:47 ` What is acceptable for -ffast-math? (Was: associative law in combine) Jan Hubicka 2001-07-18 11:30 ` associative law in combine Joern Rennecke 0 siblings, 2 replies; 13+ messages in thread From: Toon Moene @ 2001-07-18 1:01 UTC (permalink / raw) To: Joern Rennecke; +Cc: Jan Hubicka, gcc Joern Rennecke wrote: > > > Jan Hubicka wrote: > > OK, so to speak loud - where is the proper place to convert > > a/b/c to a/(b*c) at tree level. fold-const or some other? > > Only if b and c are constants, the operations are floating point, and > b can be multiplied with c without loss of precision or overflow. > Or if b and/or c is a power of two, and b can be multiplied with c without > overflow. Joern is right, Jan. One can argue about the loss of precision (under unsafe math optimisations), but not the overflow. I overlooked that issue in my reply to you. Because overflow can only be determined at compile time with constants, this conversion cannot be right for variables. -- Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction) ^ permalink raw reply [flat|nested] 13+ messages in thread
* What is acceptable for -ffast-math? (Was: associative law in combine) 2001-07-18 1:01 ` Toon Moene @ 2001-07-18 1:47 ` Jan Hubicka 2001-07-28 23:04 ` Tim Prince 2001-07-18 11:30 ` associative law in combine Joern Rennecke 1 sibling, 1 reply; 13+ messages in thread From: Jan Hubicka @ 2001-07-18 1:47 UTC (permalink / raw) To: Toon Moene; +Cc: Joern Rennecke, Jan Hubicka, gcc > Joern Rennecke wrote: > > > > > Jan Hubicka wrote: > > > > OK, so to speak loud - where is the proper place to convert > > > a/b/c to a/(b*c) at tree level. fold-const or some other? > > > > Only if b and c are constants, the operations are floating point, and > > b can be multiplied with c without loss of precision or overflow. > > Or if b and/or c is a power of two, and b can be multiplied with c without > > overflow. > > Joern is right, Jan. One can argue about the loss of precision (under > unsafe math optimisations), but not the overflow. I overlooked that > issue in my reply to you. Because overflow can only be determined at > compile time with constants, this conversion cannot be right for > variables. OK, I believe, that our concept of unsafe_math_optimizations allows such transformation, but I see, that the line between acceptable unsafe_math_optimization and unacceptable one is pretty fragine. In case -ffast-math is not enought to ask for such transformation, we probably should invent switch for that. This change (plus the other changes to avoid divisions) seems to play important role on optimizing some FP software (due to extreme cost of fp division). Honza ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What is acceptable for -ffast-math? (Was: associative law in combine) 2001-07-18 1:47 ` What is acceptable for -ffast-math? (Was: associative law in combine) Jan Hubicka @ 2001-07-28 23:04 ` Tim Prince 2001-07-29 6:33 ` Jan Hubicka 2001-07-29 10:50 ` Linus Torvalds 0 siblings, 2 replies; 13+ messages in thread From: Tim Prince @ 2001-07-28 23:04 UTC (permalink / raw) To: Jan Hubicka, Toon Moene; +Cc: Joern Rennecke, Jan Hubicka, gcc ----- Original Message ----- From: "Jan Hubicka" <jh@suse.cz> To: "Toon Moene" <toon@moene.indiv.nluug.nl> Cc: "Joern Rennecke" <amylaar@redhat.com>; "Jan Hubicka" <jh@suse.cz>; <gcc@gcc.gnu.org> Sent: Wednesday, July 18, 2001 1:44 AM Subject: What is acceptable for -ffast-math? (Was: associative law in combine) > > Joern Rennecke wrote: > > > > > > > Jan Hubicka wrote: > > > > > > OK, so to speak loud - where is the proper place to convert > > > > a/b/c to a/(b*c) at tree level. fold-const or some other? > > > > > > Only if b and c are constants, the operations are floating point, and > > > b can be multiplied with c without loss of precision or overflow. > > > Or if b and/or c is a power of two, and b can be multiplied with c without > > > overflow. > > > > Joern is right, Jan. One can argue about the loss of precision (under > > unsafe math optimisations), but not the overflow. I overlooked that > > issue in my reply to you. Because overflow can only be determined at > > compile time with constants, this conversion cannot be right for > > variables. > OK, I believe, that our concept of unsafe_math_optimizations allows such > transformation, but I see, that the line between acceptable > unsafe_math_optimization and unacceptable one is pretty fragine. > > In case -ffast-math is not enought to ask for such transformation, > we probably should invent switch for that. This change (plus the > other changes to avoid divisions) seems to play important role > on optimizing some FP software (due to extreme cost of fp division). > > Honza 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. When Honza and I first discussed this, and also the transformation for(i=0;i<n;++i) a[i]=b[i]/c; to for(i=0;i<n;++i) a[i]=b[i]*(1/c); 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). 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What is acceptable for -ffast-math? (Was: associative law in combine) 2001-07-28 23:04 ` Tim Prince @ 2001-07-29 6:33 ` Jan Hubicka 2001-07-29 10:18 ` Tim Prince 2001-07-29 10:50 ` Linus Torvalds 1 sibling, 1 reply; 13+ messages in thread From: Jan Hubicka @ 2001-07-29 6:33 UTC (permalink / raw) To: Tim Prince; +Cc: Jan Hubicka, Toon Moene, Joern Rennecke, gcc > > 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. 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. > > When Honza and I first discussed this, and also the transformation > > for(i=0;i<n;++i) > a[i]=b[i]/c; > > to > > for(i=0;i<n;++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? 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What is acceptable for -ffast-math? (Was: associative law in combine) 2001-07-29 6:33 ` Jan Hubicka @ 2001-07-29 10:18 ` Tim Prince 2001-07-29 10:26 ` Jan Hubicka 0 siblings, 1 reply; 13+ messages in thread From: Tim Prince @ 2001-07-29 10:18 UTC (permalink / raw) To: Jan Hubicka; +Cc: Jan Hubicka, Toon Moene, Joern Rennecke, gcc ----- Original Message ----- From: "Jan Hubicka" <jh@suse.cz> To: "Tim Prince" <tprince@computer.org> Cc: "Jan Hubicka" <jh@suse.cz>; "Toon Moene" <toon@moene.indiv.nluug.nl>; "Joern Rennecke" <amylaar@redhat.com>; <gcc@gcc.gnu.org> 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 <mathinline.h>. 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<n;++i) > > a[i]=b[i]/c; > > > > to > > > > for(i=0;i<n;++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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What is acceptable for -ffast-math? (Was: associative law in combine) 2001-07-29 10:18 ` Tim Prince @ 2001-07-29 10:26 ` Jan Hubicka 2001-07-29 12:11 ` Tim Prince 0 siblings, 1 reply; 13+ messages in thread From: Jan Hubicka @ 2001-07-29 10:26 UTC (permalink / raw) To: Tim Prince; +Cc: Jan Hubicka, Toon Moene, Joern Rennecke, gcc > 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 > <mathinline.h>. It allows The mathinline is mostly mess. I was thinking about rewriting it myself. It seems to make sense to make target specific builtins for the i387 features the header needs and use them, instead of using mostly unusable i387 inline assembly. If you have sanified version and you can get the copyring issues, please try to contribute the changed to glibc. > 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. The description quoted above states, that FLAG_FAST_MATH is defined and so glibc is correct IMO to change the behaviour. > > > > 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. OK, I will document the new options in -ffast-math, as we document these on -Ox and send a patch shortly. > 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. We may jump into something like -fapproximate-fp-math allowing transformation with loss of effciency if that makes sense. > > 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, You can turn them individually and if they are not documented, I will do so shortly. Honza ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What is acceptable for -ffast-math? (Was: associative law in combine) 2001-07-29 10:26 ` Jan Hubicka @ 2001-07-29 12:11 ` Tim Prince 2001-07-29 12:17 ` Jan Hubicka 0 siblings, 1 reply; 13+ messages in thread From: Tim Prince @ 2001-07-29 12:11 UTC (permalink / raw) To: Jan Hubicka; +Cc: Jan Hubicka, Toon Moene, Joern Rennecke, gcc ----- Original Message ----- From: "Jan Hubicka" <jh@suse.cz> To: "Tim Prince" <tprince@computer.org> Cc: "Jan Hubicka" <jh@suse.cz>; "Toon Moene" <toon@moene.indiv.nluug.nl>; "Joern Rennecke" <amylaar@redhat.com>; <gcc@gcc.gnu.org> Sent: Sunday, July 29, 2001 10:24 AM Subject: Re: What is acceptable for -ffast-math? (Was: associative law in combine) > The mathinline is mostly mess. I was thinking about rewriting it myself. > It seems to make sense to make target specific builtins for the i387 > features the header needs and use them, instead of using mostly unusable > i387 inline assembly. glibc as a whole is so dependent on i386 assembly that it would be a major project to change. It might be interesting to include direct support for more math intrinsics in gcc, but that begins to encroach on the traditional separation between gcc and support libraries. I suppose this would involve built-ins for frexp(), ldexp() et al. in each supported precision. I fear that a noticeable amount of efficiency could be lost, and we would remain with the question of full accuracy and safety vs speed in certain cases. A beginning would be to organize mathinline.h so as to be based on such a group of builtins in order to test them in the current framework. This project may not offer sufficient return without assurance of glibc taking advantage of it and becoming more portable. > > If you have sanified version and you can get the copyring issues, > please try to contribute the changed to glibc. I took this far enough with the glibc maintainers to see that their point of view does not allow introduction of any "safety features." Now I will be even further away, wanting to improve support for P4. > > > > 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, > > You can turn them individually and if they are not documented, I will do > so shortly. Thanks > > Honza ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What is acceptable for -ffast-math? (Was: associative law in combine) 2001-07-29 12:11 ` Tim Prince @ 2001-07-29 12:17 ` Jan Hubicka 0 siblings, 0 replies; 13+ messages in thread From: Jan Hubicka @ 2001-07-29 12:17 UTC (permalink / raw) To: Tim Prince; +Cc: Jan Hubicka, Toon Moene, Joern Rennecke, gcc > glibc as a whole is so dependent on i386 assembly that it would be a > major project to change. It might be interesting to include direct Gcc currently have an method to add machine dependent builtins used by the SSE code. I think in same sense we can add machine dependent builtins for the few remaining i387 instructions we don't generate directly and then use mathinline.h to do right job converting them to 'C' way. I believe this is clean solution. > support for more math intrinsics in gcc, but that begins to encroach on > the traditional separation between gcc and support libraries. I suppose > this would involve built-ins for frexp(), ldexp() et al. in each > supported precision. I fear that a noticeable amount of efficiency I must say I don't follow the above... > could be lost, and we would remain with the question of full accuracy > and safety vs speed in certain cases. A beginning would be to organize > mathinline.h so as to be based on such a group of builtins in order to > test them in the current framework. This project may not offer This sounds exactly what I say :) So we seems to be in tune. Honza > sufficient return without assurance of glibc taking advantage of it and > becoming more portable. > > > > If you have sanified version and you can get the copyring issues, > > please try to contribute the changed to glibc. > I took this far enough with the glibc maintainers to see that their > point of view does not allow introduction of any "safety features." Now > I will be even further away, wanting to improve support for P4. I ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What is acceptable for -ffast-math? (Was: associative law in combine) 2001-07-28 23:04 ` Tim Prince 2001-07-29 6:33 ` Jan Hubicka @ 2001-07-29 10:50 ` Linus Torvalds 1 sibling, 0 replies; 13+ messages in thread From: Linus Torvalds @ 2001-07-29 10:50 UTC (permalink / raw) To: tprince, gcc In article < 004501c117f4$84a48c80$9865fea9@timayum4srqln4 > you write: > >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. Note that with FP math, especially with C, there are mainly two kinds of people: - those who know and care about underflows, overflows and precision. They _sometimes_ also want exact IEEE semantics, but not necessarily. - those who don't, and don't want to, and just want fast code. Why not make this easier for the user: - default to non-IEEE, but "reasonably safe". Allow optimizations that underflow or aren't precise to ULP - or optimizations that extend the range of calculations (ie keep things in "double" or "long double" longer than strictly allowed), but don't allow optimizations that can make the range of operations smaller (ie extra traps are bad). - make "-ffast-math" mean exactly that: fast. Even at the expense of being even more incorrect, ie allowing optimizations that might overflow. Let's face it - they are quite rare, especially in code that doesn't care. Make "-ffast-math" be the generic "if you don't know, and if you don't care, use this option" for people who just want ultimate speed for their quake3 thing. - make the people who _do_ know what they are doing and _do_ know what the options mean have extra options on just how careful they can be. It's silly and counter-productive to assume that most people would know what "-ffast-div" is. So for real math, you'd have - "-mieee": This turns us into anal animals, and often implies using different math libraries etc too. No "reasonable safe" optimizations except the ones explicitly allowed by standards. - "-ffloat-precision": allow optimizations that might lose precision. - "-ffloat-div-reciprocal": allow optimizations with turning divides into reciprocals etc. ... But don't make "-ffast-math" imply "it's still safe". Please. So do allow Honza's optimization under fast-math. Don't allow it by default, and NEVER allow it with "-mieee" unless we start doign the Fortran thing. That way, we can also have a simple benchmarking rule: use "-O2 -ffast-math" for benchmarks. No need to tell people about the latest "-ffloat-random-optimization" of the day, which changes with compiler releases anyway. Linus ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: associative law in combine 2001-07-18 1:01 ` Toon Moene 2001-07-18 1:47 ` What is acceptable for -ffast-math? (Was: associative law in combine) Jan Hubicka @ 2001-07-18 11:30 ` Joern Rennecke 1 sibling, 0 replies; 13+ messages in thread From: Joern Rennecke @ 2001-07-18 11:30 UTC (permalink / raw) To: Toon Moene; +Cc: Joern Rennecke, Jan Hubicka, gcc > issue in my reply to you. Because overflow can only be determined at > compile time with constants, this conversion cannot be right for > variables. Actually, as with most rules, there is an exception here: if b and c are widened, or are constants that fit into a type with less precision, we can widen before the multiply, or, even better, we can use a wideining multiply (if available). e.g.: long long a; int b, c; or: double a; float b, c; or: double a; float b; a = a / b / 42 However, that might be to rare to be worth the effort. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2001-07-29 12:17 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20010716224423.F29145@atrey.karlin.mff.cuni.cz> [not found] ` <3B547DF4.7F39BF61@moene.indiv.nluug.nl> [not found] ` <20010717200629.E5166@atrey.karlin.mff.cuni.cz> [not found] ` <3B5489F1.54DE59CE@moene.indiv.nluug.nl> [not found] ` <20010717205837.I5166@atrey.karlin.mff.cuni.cz> [not found] ` <3B548CBF.DDD59F97@moene.indiv.nluug.nl> [not found] ` <20010717211516.N5166@atrey.karlin.mff.cuni.cz> [not found] ` <3B548FAA.E174E765@moene.indiv.nluug.nl> 2001-07-17 12:23 ` associative law in combine Jan Hubicka 2001-07-17 15:41 ` Dima Volodin 2001-07-17 15:59 ` Joern Rennecke 2001-07-18 1:01 ` Toon Moene 2001-07-18 1:47 ` What is acceptable for -ffast-math? (Was: associative law in combine) Jan Hubicka 2001-07-28 23:04 ` Tim Prince 2001-07-29 6:33 ` Jan Hubicka 2001-07-29 10:18 ` Tim Prince 2001-07-29 10:26 ` Jan Hubicka 2001-07-29 12:11 ` Tim Prince 2001-07-29 12:17 ` Jan Hubicka 2001-07-29 10:50 ` Linus Torvalds 2001-07-18 11:30 ` associative law in combine Joern Rennecke
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).