/internet

[tprince at cat dot e-mail dot com]

The question of possible over/underflow of intermediate results is more relevant for floating point than
for integer multiplication.  However, I believe most people consider that the programmer is obligated
to use parentheses to enforce safe grouping, if there is a known such grouping. If the program was
originally tested on Intel, this is not likely to have been considered!  Reassociation is commonly
required for adequate performance of a series of additions, and there of course accuracy is more
likely to be an issue than over/underflow.

I try to make a practice of using appropriate parentheses in an expression such as

(a-b) + (c-d) + (e-f)

where that may improve accuracy (given that the differences are known to be relatively small) as well
as suggesting an effective pipelined grouping.  Possibly this would deserve an FAQ treatment if
egcs/gnu begins to do reassociations.

Treatment of reassociation is by no means uniform.  I just accepted Arnaud Desitter's suggestion of a
usage of Kahan summation to improve the portability of the check-summing in Livermore Fortran
Kernel.  It turns out that the Irix (MipsPro7.2) compiler requires the option -OPT:fold_reassociate=OFF
in conjunction with optimization, in order for this to work.   They treat neglect of parentheses and order
of assignments, as well as changing the sense of comparison, as a normal consequence of full
optimization.  Of course, in that case, the intended data dependencies require 4 times as many cycles
as the "optimized" code, but that's still faster than REAL*16 on some machines.

This optimization doesn't matter on Intel in extended precision mode, but one of the compilers I tested
apparently sets double precision mode.  I tried declaring "real(selected_real_kind(18)) sum" to make
a strong suggestion that the compiler should use extended precision or REAL*16, but certain
compilers rejected this entirely, and g77 has not adopted this syntax.
____________________________________________

>>For FP, we would like the ability to reassociate some expressions.  Take
(a * b * c * d) * e

>>Right now we'll genrate

t1 = a * b;
t2 = t1 * c;
t3 = t2 * d;
t4 = t3 * e;

>>Note the dependency of each insn on the previous insn.  This can be a major
performance penalty -- especially on targets which have dual FP units or where
a fpmul isn't incredibly fast (data dependency stalls at each step).

t1 = a * b;
t2 = c * d;
t3 = t1 * t2;
t4 = t3 * e;


>>Is a much better (and safe as far as I know) sequence.  The first two insns
are totally independent, which at the minimum reduces one of the 3 stall
conditions due to data dependency.  For a target with a pipelined FPU or
dual FPUs the second sequence sequence will be significantly faster.


>>For integer, we need to know where the parens are to preserve integer overflow
semantics in languages like Ada for similar transformations.


jeff<<

-
Dr. Timothy C. Prince
Consulting Engineer
Solar Turbines, a Caterpillar Company
alternate e-mail: tprince@computer.org

           To:                                              INTERNET - IBMMAIL
                                                            N0520484 - IBMMAIL