Polyhedron tests on Intel Darwin8/9

[Dominique Dhumieres]

> Unfortunately, it takes twice as long to execute....

If the 'if' in

                      if (tmp1.218 == z1.217 || tmp2.220 == z2.219)
                        {
                          (void) 0;
                        }
                      else
                        {
                          val.216 = val.216 + tmp1.218 * tmp2.220;
                        }

is not resolved by the middle end, it will certainly take longer to
evaluate the block than to compute the muladd directly.  From some
tests, it seems that this the case for -O and above if the test involves
constants, i.e., it will probably remove a muladd for induct.f90.
However I am afraid that the two other 'if's cannot be resolved
at compile time and I doubt that the optimizer will be smart enough
to see that the block is equivalent to
val.216 = val.216 + tmp1.218 * tmp2.220;
for any case. Since on today processors, the cost of 'if's is higher than
those of muladd, I am not really surprized by your result.

I have also looked at the following test:

integer :: i
real :: a1, b1, pi, s, th
pi = acos(-1.0)
th = pi/128.0
s = 0.0
do i = 1, 128
   a1 = cos(i*th)
   b1 = 0.0
   s = s + a1*b1
end do
print *, s
end

in PPC assembly with -O3, the inner loop is:

L2:
        xoris r0,r29,0x8000
        stw r30,344(r1)
        stw r0,348(r1)
        lfd f1,344(r1)
        fsub f1,f1,f30
        frsp f1,f1
        fmuls f1,f1,f28
        bl L_cosf$stub
        cmpwi cr7,r29,128
        fmadds f31,f1,f29,f31
        addi r29,r29,1
        bne+ cr7,L2

with a fmadds corresponding to 's = s + a1*b1'.
So even at -O3 the gcc optimizer is unable to see that
a1*b1 is always zero, even if b1 is a constant (in this case
a "perfectly" optimized code would reduce to

print *, 0.0

and this is not the case.

Speaking of optimization, I think the front-end should not try to do
any optimization itself, unless it has information that are not passed
to the next stages.  One example could be inlining.  This is why I would
understand better why the channel variant in which I have hand-inlined
some functions is faster than the oribinal version, while I have understood
than contained functions are inlined (is this true? specially if the
function is in a module?).

Also it would be nice that the people working on the middle-end correlate
their changes to the available timings within days and not after bug
reports.

Dominique