ipo optimization problem with icc 9.0.030

[wagenerm]

I am currently porting an application from mips/IRIX to ia64/Linux and I am encountering some problems with ipo optimization. I have nailed down the problem to the optimization of one ca. 20 line function. The result of this function changes if ipo optimization is turned on.

BTW, the routine gives the expected results under IRIX (32 and 64 bit executable) and on i686/Linux with gcc.

Are there any know issues with ipo optimization?

I appreciate any feed-back,

Markus

[TimP]

Obviously, a known issue with ipo is a greater opportunity for bugs to show up. Without detailed information, no one could guess whether it should be considered a compiler issue or a problem in the source code. I don't even think "works with gcc" is a useful generalization, unless you have tested thoroughly with recent versions, such as 4.1. If you haven't turned on full compilation diagnostics, both with icc and gcc, please try it.

[wagenerm]

Obviously, I had compiled the problematic sources with the -Wall option turned on, and I didn't get any warnings but the one on "controlling expression is constant" for the common idiom do {....} while(0) used for macros. And the program is also clean with purify (under IRIX).

I attach the routine that causes the error when optimized with -ipo to this message. This piece of code alone does not show the bug, but that cannot be expected for an ipo problem. Unfortunately, I did not succeed in isolating the bug in a small piece of code.

I would appreciate very much if you could give me some advise on how to address/solve the problem.

Markus

[TimP]

You may want to check hand optimizations here. If it isn't valid to write
c = VECDOT(n1, n2)/sqrt(VECLEN(n1) * VECLEN(n2));
then you may need to throw -mp1 or -mp or -fp-model:precise to inhibit unsafe optimization.
Writing DET in a more efficient form, with less opportunity to group terms unsafely, may be more worthwhile than attempting IPO.

[wagenerm]

Tim,

thanks for the suggestions, I tried all three floating point options (-mp -mp1 and -fp-model precise), but none of them solved my original problem.

What do you mean by writing DET in a form that allows less unsafe grouping of terms? Could you please give an example?

In the meantime I have experimented with putting printf statements at different places, and I got the feeling that when inlining torsion_angle(), the 4th parameter (i.e. POINT p4)is not always properly assigned. But this is tricky since the printfs themselves change the behavior of the program as well...

Markus

[TimP]

For example:
#define DET(a, b, c)
((a).x*((b).y*(c).z - (c).y*(b).z) +
(b).x*((c).y*(a).z - (a).y*(c).z) +
(c).x*((a).y*(b).z - (b).y*(a).z))

On the face of it, for in-lining to show any benefit, the compiler would have to find a way to eliminate at least one level of conditionals. If you know that is a valid optimization, you might consider writing your code so that is clear.

[TimP]

If you aren't trying to prevent optimization, why not use fabs() rather than that ABS() macro? It's been a long time since I've seen a compiler which didn't in-line fabs().

[wagenerm]

I did some further experiments to identify the problem.

Remember, the routine torsion_angle(), which I posted in a previous message, gives different results depending on whether it is compiled with or without the ipo option.

I now changed the function from:

VECTYPE torsion_angle(POINT p1, POINT p2, POINT p3, POINT p4)

to

VECTYPE torsion_angle(POINT p[4])
{
   POINT   p1 = p[0];
   POINT   p2 = p[1];
   POINT   p3 = p[2];
   POINT   p4 = p[3];
...

And the changed version (with POINT p[4] as an argument) now gives the correct result with and without ipo.

Does that mean that ipo could somehow get confused by the four arguments?

Markus

[TimP]

That is curious. In my opinion, it does strengthen the case there may be a compiler bug here.