This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: weird optimization in sin+cos, x86 backend

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'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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]