Re: [PATCH] pow and atan2 builtin functions (part 3)

[Roger Sayle <roger at www dot eyesopen dot com>]

Hi Richard,

On Tue, 11 Feb 2003, Richard Henderson wrote:
> On Mon, Feb 10, 2003 at 08:07:21PM -0700, Roger Sayle wrote:
> > + 	      case UNSPEC_FLDLG2:
> > + 	      case UNSPEC_FLDLN2:
> > + 	      case UNSPEC_FLDL2E:
> > + 	      case UNSPEC_FLDL2T:
> > + 	      case UNSPEC_FLDPI:
>
> These I don't like.  I'd rather we matched the exact XFmode
> value in standard_80387_constant_p.  See also the note about
> these being slower than a load from memory on some targets.


You'll notice that I explicitly didn't include "fldz" and "fld1"
in this list.  Both of these constants can be represented exactly
in both SF and DF mode, loaded efficiently and extended to full
precision internally.  Hence, use of these constants in user-source
code or splitter patterns in .md files, should use the usual "mov?f"
patterns, where standard_80387_constant_p can recognize them and
choose whichever is faster for the target.

The constants listed above however cannot be represented exactly
in either SF and/or DF mode, requiring an XF mode load.  In theory,
different x86 vendors are free to provide different levels of
precision for these constants (beyond 80 bits), or use additional
hardware to track their use in other x87 instructions, so the use
of "fldpi" is not guaranteed to be equivalent to any available
"fld st(0)" instruction on a processor.

I believe this is one of the reasons that standard_80387_constant_p
doesn't currently recognize and use these instructions for constants
in RTL.

I defined the UNSPEC indices in this patch so they could be used
internally by define_expand, which can use them effectively, for example
to implement "logdf2".  Per your suggestion in :>
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00250.html


If you still think standard_80387_constant_p *should* be extended to
handle these constants via the usual mechanism, you might consider
something like Daniel Jungmann's patch from October 2001:

http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01166.html

which is actually the third or fourth patch revision resulting
from a long thread back when this was last discussed.

Roger
--