On Feb 10, 2012, at 05:07, Richard Guenther wrote: > On Thu, Feb 9, 2012 at 8:16 PM, Geert Bosch <bo...@adacore.com> wrote: >> 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).
I'm probably oversimplifying a bit, but I see extra entry points as being similar to inlining. When you write sin (x), this is a function not only of x, but also of the implicit rounding mode and special checking options. With that view specializing the sin function for round-to-even is essentially a form of partial inlining. Also, evaluation of a single math function typically has high latency as most instructions depend on results of previous instructions. For optimal throughput, you'd really like to be able to schedule these instructions. Anyway, those are implementation details. The main point is that we don't want to be bound by a frozen interface with the math routines. We'll want to change the interface when we have new functionality or optimizations. > 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). Right. I even understand where he is coming from. Adding new interfaces is indeed a big deal as they'll pretty much have to stay around forever. We need something more flexible that is tied to the compiler and not a fixed interface that stays constant over time. Even if we'd add things to glibc now, it takes many years for that to trickle down. Of course, a large number of GCC uses doesn't use glibc at all. >> 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. Agreed. >> 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 ... Yes, that seems like a good plan. Now, how do we start this? As a separate project or just as part of GCC? -Geert
