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]

Re: What is acceptable for -ffast-math? (Was: associative law in combine)


<<Well, that might be because we're on a public list and I, certainly, am
not going to name names of competitors.  Granted, I do not have an
actual proof of a Fortran compiler that substituted (a+b)*c for a*b+a*c,
but I have seen those that:
>>

Well you should certainly not hesitate to name compilers here, this is hardly
a sensitive issue, and indeed there are those on this list who think that
associative rearrangement *is* an appopriate "optimization" even if it
introduces overflow where none existed for the canonical evaluation.

But in fact, as you make clear, you don't in fact know of any Fortran compiler
that does associative rearrangement, and I repeat my point ... I would be
surprised if there is any such in existence.

<<2. Included an option to use floating point induction variables, i.e.,
   change:

      DO I = 1, N
         A(I) = I * 0.1
      ENDDO

   into:

      T = 0.0
      DO I = 1, N
         T = T + 0.1
         A(I) = T
      ENDDO
>>

Must be an old compiler. I can't think of any modern machine where such a
change would make a difference. Floating-point IEEE addition is typically
at least as difficult, sometimes one pipeline stage harder, than floating-point
multiplication, so that's a pretty pointless transformation on modern machines
as well as being a real horror (this not a case where the error is limited
to a few ULP!)

And that's really the point. For modern machines, are we really talking
about transformations that make any difference to the performance? Not
once in this long discussoin has anyone provided even the tiniest smidgeon
of quantitative support for the position that you do see a real performance
difference in real programs. Linus may declare that he knows that this is
a significant issue, and call people silly if they disagree, but that hardly
counts as quantitative data :-)


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