This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/24123] [4.1 Regression] Massive performance regression for -ffast-math due to the recip tree pass
- From: "paolo dot bonzini at lu dot unisi dot ch" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Sep 2005 14:14:04 -0000
- Subject: [Bug tree-optimization/24123] [4.1 Regression] Massive performance regression for -ffast-math due to the recip tree pass
- References: <20050929140549.24123.uros@kss-loka.si>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From paolo dot bonzini at lu dot unisi dot ch 2005-09-30 14:13 -------
Subject: Re: [4.1 Regression] Massive performance
regression for -ffast-math due to the recip tree pass
>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.
>
>
no, there is another user in another basic block.
>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.
>
>
I think the final DOM run ought to simplify the other problems.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24123