Polyhedron tests on Intel Darwin8/9

[Janne Blomqvist]

Dominique Dhumieres wrote:
> 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 

As Andrew hinted at, you can't optimize away this without breaking IEEE 
754 conformance. Try -ffast-math.

Now, I suppose one could argue that Fortran != IEEE 754, and that 
Fortran allows mathematically equivalent transformations, so by default 
gfortran should be a little bit looser than gcc (not as loose as 
everything in -ffast-math though). However, there has been discussion 
about FP optimization in gcc in general, so perhaps gfortran should wait 
for some kind of consensus there before doing any drastic changes. See

http://gcc.gnu.org/wiki/FP_BOF

http://gcc.gnu.org/wiki/GeertBosch

http://gcc.gnu.org/wiki/Math_Optimization_Flags

> 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.

Yes, that's pretty much how it's done already. AFAIK the only 
optimizations done in the frontend are array expression optimizations, 
typically to avoid creating temporaries.

>  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?).

Yes, there are long-standing problems preventing inlining or other types 
of IPO for public symbols (something to do with duplicate symbols, among 
other things, IIRC).

-- 
Janne Blomqvist