Re: weird optimization in sin+cos, x86 backend

[Richard Guenther <richard dot guenther at gmail dot com>]

On Thu, Feb 9, 2012 at 8:16 PM, Geert Bosch <bosch@adacore.com> wrote:
>
> On Feb 9, 2012, at 12:55, Joseph S. Myers wrote:
>
>> No, that's not the case. ?Rather, the point would be that both GCC's
>> library and glibc's end up being based on the new GNU project (which might
>> take some code from glibc and some from elsewhere - and quite possibly
>> write some from scratch, taking care to ensure new code is properly
>> commented and all constants are properly explained with free software code
>> available to calculate all the precomputed tables). ?(Is
>> sysdeps/ieee754/dbl-64/uatan.tbl in glibc - a half-megabyte file of
>> precomputed numbers - *really* free software? ?No doubt it wouldn't be
>> hard to work out what the numbers are from the comment "x0,cij for
>> (1/16,1)" and write a program using MPFR to compute them - but you
>> shouldn't need such an exercise to figure it out, such generated tables
>> should come with free software to generate them since the table itself
>> certainly isn't the preferred form for modification.)
>
> I don't agree having such a libm is the ultimate goal. It could be
> a first step along the way, addressing correctness issues. This
> would be great progress, but does not remove the need for having
> at least versions of common elementary functions directly integrated
> with GCC.
>
> In particular, it would not address the issue of performance. For
> that we need at least a permissive license to allow full inlining,
> but it seems unlikely to me that we'd be able to get glibc code
> under those conditions any time soon.

I don't buy the argument that inlining math routines (apart from those
we already handle) would improve performance.  What will improve
performance is to have separate entry points to the routines
to skip errno handling, NaN/Inf checking or rounding mode selection
when certain compilation flags are set.  That as well as a more
sane calling convention for, for example sincos, or in general
on x86_64 (have at least _some_ callee-saved XMM registers).

The issue with libm in glibc here is that Drepper absolutely does
not want new ABIs in libm - he believes that for example vectorized
routines do not belong there (nor the SSE calling-convention variants
for i686 I tried to push once).

> I'd rather start collecting suitable code in GCC now. If/when a
> libm project materializes, it can take our freely licensed code
> and integrate it. I don't see why we need to wait.
> Still, licensing is not the only issue for keeping this in GCC.

True.  I think we can ignore glibc and rather think as of that newlib
might use it if we're going to put it in toplevel src.

> From a technical point of view, I see many reasons to tightly couple
> implementations of elementary functions with the compiler like we
> do now for basic arithmetic in libgcc. On some targets we will
> want to directly implement elementary functions in the back end,
> such as we do for sqrt on ia64 today. ?In other cases we may want
> to do something similar in machine independent code.
>
> I think nowadays it makes as little sense to have sqrt, sin, cos,
> exp and ln and other common simple elementary functions in an
> external library, as it would be for multiplication and division to
> be there. Often we'll want to generate these functions inline taking
> advantage of all knowledge we have about arguments, context, rounding
> modes, required accuracy, etc.
>
> So we need both an accurate libm, and routines with a permissive
> license for integration with GCC.

And a license, that for example allows installing a static library variant
with LTO bytecode embedded so we indeed _can_ inline and re-optimize it.
Of course I expect the fastest paths to be architecture specific assembly
anyway ...

Richard.

>
> ?-Geert