Re: [PATCH] implement log10 and log2 functions as x87 builtins

[Roger Sayle <roger at eyesopen dot com>]

On Tue, 10 Feb 2004, Uros Bizjak wrote:
> +2003-02-10  Uros Bizjak <uros@kss-loka.si>
> +
> +    * optabs.h (enum optab_index): Add new OTI_log10 and OTI_log2.
> +    (log10_optab, log2_optab): Define corresponding macros.
> +    * optabs.c (init_optabs): Initialize log10_optab and log2_optab.
> +    * genopinit.c (optabs): Implement log10_optab and log2_optab
> +    using log10?f2 and log2?f2 patterns.
> +    * builtins.c (expand_builtin_mathfn): Handle BUILT_IN_LOG10{,F,L}
> +    using log10_optab, and BUILT_IN_LOG2{,F,L} using log2_optab.
> +    (expand_builtin): Expand BUILT_IN_LOG10{,F,L} and BUILT_IN_LOG2{,F,L}
> +    using expand_builtin_mathfn if flag_unsafe_math_optimizations is set.
> +
> +    * config/i386/i386.md (log10sf2, log10df2, log10xf2, log2sf2,
> +    log2df2, log2xf2): New patterns to implement log10, log10f, log10l
> +    log2, log2f and log2l  built-ins as inline x87 intrinsics.

Hi Uros,

The patch itself looks fine.  However to large accept contributions to
GCC we need to have a FSF copyright assignment on file.  You'll need to
send an e-mail to assignments@gnu.org requesting the relevant forms.

If this is a problem, let me know.


For this patch, its also a good idea to include a new testcase or two.
All that's required is a simple check that "log2" and "log10" can be
called (probably both with compile-time constants or with variables) in
their float, double and long double forms with -ffast-math on x86.  You
don't even need to check the return values.  This ensures that all of
the new code added by your patch is executed atleast once in gcc's
testsuite, and prevents someone from breaking it in the future.

Take a look at testsuite/gcc.dg/builtins-15.c for an example.
Perhaps something like

  double test1(double x)
  {
    return log2(x);
  }

  float test1f(float x)
  {
    return log2f(x);
  }

  ...

  double test2(double x)
  {
    return log10(x);
  }

  ...


Once the paperwork is sorted out, there should be no problem getting
this patch approved and committed to mainline for gcc 3.5.

Many thanks,

Roger
--