Re: weird optimization in sin+cos, x86 backend

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

On Fri, Feb 10, 2012 at 5:25 PM, Geert Bosch <bosch@adacore.com> wrote:
>
> On Feb 10, 2012, at 05:07, Richard Guenther wrote:
>
>> On Thu, Feb 9, 2012 at 8:16 PM, Geert Bosch <bosch@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?

As we are probably going to tightly couple GCC codegen with the libm
ABI we should have the goal of having libm as another target library
for GCC (otherwise we'll end up with a myriad of configure-time checks
there ...).  So I'd say start it on a branch in the GCC repository and
schedule it for a GCC 4.8 merge.  There are two main things to concentrate
on - a sensible (target specific) ABI towards GCC for optimization
(both the vectorizer ABI and the -f{...}-math ABIs) and providing an accurate
C99 math implementation for targets that lack it.  Initially we might just
try to fix the ABI side, dispatching to the target OS libm, and put in some
testsuite mechanics (I'm thinking of randomized testing with testing against
mpfr results, with automatic fixed-value testcase generation for future
regression testing).

Richard.

> ?-Geert
>