[Bug tree-optimization/24123] [4.1 Regression] Massive performance regression for -ffast-math due to the recip tree pass

[uros at kss-loka dot si]

------- Additional Comments From uros at kss-loka dot si  2005-09-30 13:58 -------
Looking at the differences, the result of recip looks _really_ good!

Currently, there seems to be some problems, i.e.:

double pov::f_polytubes(double*, unsigned int) (ptr, D.22748)

-  D.22787_46 = -6.28318530717958623199592693708837032318115234375e+0 / D.22783_80;
+  reciptmp.882_72 = 1.0e+0 / D.22783_80;
+  D.22787_46 = -6.28318530717958623199592693708837032318115234375e+0 *
reciptmp.882_72;

Not needed, only one user.


Function double pov::POVFPU_RunDefault(pov::FUNCTION)

 <L193>:;
-  r0_1660 = r0_89 / r0_89;
+  reciptmp.492_84 = 1.0e+0 / r0_89;
+  r0_1660 = r0_89 * reciptmp.492_84;
   goto <bb 1062> (<L1339>);

The result of above confusion is (1.0)! We are in fast-math, so no NaNs, etc..

void pov::Simulate_Media(pov::IMEDIA**, pov::RAY*, pov::INTERSECTION*
-  reciptmp.1152_907 = 1.0e+0 / prephitmp.1124_293;
-  reciptmp.1153_1046 = 1.0e+0 / prephitmp.1124_293;
-  reciptmp.1154_1041 = 1.0e+0 / prephitmp.1124_293;
+  reciptmp.1275_1270 = 1.0e+0 / prephitmp.1124_293;
+  reciptmp.1152_907 = 1.0e+0 * reciptmp.1275_1270;
+  reciptmp.1153_1046 = 1.0e+0 * reciptmp.1275_1270;
+  reciptmp.1154_1041 = 1.0e+0 * reciptmp.1275_1270;

These are all the same? There are already reciptmp variables in loopdone that
are all the same. And there are quite some places that have this problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24123