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: "uros at kss-loka dot si" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Sep 2005 14:37:56 -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 uros at kss-loka dot si 2005-09-30 14:37 -------
(In reply to comment #18)
> >Currently, there seems to be some problems, i.e.:
> >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..
> I think the final DOM run ought to simplify the other problems.
Unfortunatelly, it doesn't.
This is from .optimized:
<L193>:;
r0 = r0 * 1.0e+0 / r0;
goto <bb 1062> (<L1339>);
And gcc further generates this beauty:
.L236:
.loc 1 1405 0
fldl -112(%ebp)
fdiv %st(0), %st
fstpl -112(%ebp)
.loc 1 1626 0
addl $1, %edi
jmp .L1595
.L237:
Some optimization pass should figure out that fld1 should do the trick...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24123