Re: Combine misses commutativity

[Paulo J. Matos]

On Fri, 10 Feb 2012 11:00:43 -0800, Richard Henderson wrote:

> On 02/10/2012 08:57 AM, Paulo J. Matos wrote:
>> However, there's a failure to combine looking like: (parallel [
>> (set (reg:QI 1 AL)
>> (ior:QI (mem/c/i:QI (reg/f:QI 4 AP) [2 y+0 S1 A16])
>> (reg:QI 30 [ x+1 ])))
>> (clobber (reg:CC 13 CC))
>> ])
> 
> Why do you think that combine should create this?
> 

Because combine tries to combine two insns to create it and fails. it 
shouldn't because ior is commutative and I have a rule accepting the 
first operand to be a register and the second to be general operand. That 
would fit if combine would swap the operands to ior.

> Really, I'd have expected swap_commutative_operands_p to have put things
> around the other way.  

Me too.

> That's the way that almost all cisc machines
> represent their memory operands.
> 

Agreed, but doesn't seem to be the case.

> ... Although I don't see any specific test for this in the code for
> commutative_operand_precedence.  That's probably at least a think-o.
> 
> 

I will take a look. Thanks for the pointer.

Cheers,

Paulo Matos

> r~





-- 
PMatos

Re: weird optimization in sin+cos, x86 backend

[Richard Guenther]

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

Re: weird optimization in sin+cos, x86 backend

[Vincent Lefevre]

On 2012-02-09 16:01:48 +, Andrew Haley wrote:
> On 02/09/2012 03:59 PM, Richard Guenther wrote:
> > On Thu, Feb 9, 2012 at 4:57 PM, Andrew Haley  wrote:
> >> On 02/09/2012 03:56 PM, Michael Matz wrote:
> >>> Hi,
> >>>
> >>> On Thu, 9 Feb 2012, Andrew Haley wrote:
> >>>
>  On 02/09/2012 03:28 PM, Richard Guenther wrote:
> > So - do you have an idea what routines we can start off with to get
> > a full C99 set of routines for float, double and long double?  The last
> > time I was exploring the idea again I was looking at the BSD libm.
> 
>  I'd start with INRIA's crlibm.
> >>>
> >>> Not complete.  Too slow.
> >>
> >> Not complete, fair enough.  But it's the fastest accurate one,
> >> isn't it?
> > 
> > Maybe.  Nothing would prevent us from composing from multiple sources
> > of course.  crlibm also only provides double precision routines.
> 
> Okay, but the crlibm algorithms could be extended to long
> doubles and, presumably, floats.  Where's Vincent Lefevre
> when you need him?   :-)

I'm a bit late at reading and answering all my mail. :)

Our team has new tools to support other precisions, so that
long double would be possible.

Also note that CRlibm supports the 4 rounding modes, while the
IBM Accurate Mathematical Library currently used in glibc behaves
erratically (e.g. can even crash) on directed rounding modes.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: weird optimization in sin+cos, x86 backend

[Andrew Haley]

On 02/13/2012 01:11 PM, Vincent Lefevre wrote:
> On 2012-02-09 16:01:48 +, Andrew Haley wrote:
>> On 02/09/2012 03:59 PM, Richard Guenther wrote:

>>> Maybe.  Nothing would prevent us from composing from multiple sources
>>> of course.  crlibm also only provides double precision routines.
>>
>> Okay, but the crlibm algorithms could be extended to long
>> doubles and, presumably, floats.  Where's Vincent Lefevre
>> when you need him?   :-)
> 
> I'm a bit late at reading and answering all my mail. :)
> 
> Our team has new tools to support other precisions, so that
> long double would be possible.
> 
> Also note that CRlibm supports the 4 rounding modes, while the
> IBM Accurate Mathematical Library currently used in glibc behaves
> erratically (e.g. can even crash) on directed rounding modes.

I think there is some consensus that crlibm is a great place to start
for correctly-rounded elementary functions.  I think we'd need, or at
least greatly appreciate, some help from your team.

Andrew.

Re: weird optimization in sin+cos, x86 backend

[Richard Guenther]

On Mon, Feb 13, 2012 at 2:32 PM, Andrew Haley  wrote:
> On 02/13/2012 01:11 PM, Vincent Lefevre wrote:
>> On 2012-02-09 16:01:48 +, Andrew Haley wrote:
>>> On 02/09/2012 03:59 PM, Richard Guenther wrote:
>
 Maybe.  Nothing would prevent us from composing from multiple sources
 of course.  crlibm also only provides double precision routines.
>>>
>>> Okay, but the crlibm algorithms could be extended to long
>>> doubles and, presumably, floats.  Where's Vincent Lefevre
>>> when you need him?   :-)
>>
>> I'm a bit late at reading and answering all my mail. :)
>>
>> Our team has new tools to support other precisions, so that
>> long double would be possible.
>>
>> Also note that CRlibm supports the 4 rounding modes, while the
>> IBM Accurate Mathematical Library currently used in glibc behaves
>> erratically (e.g. can even crash) on directed rounding modes.
>
> I think there is some consensus that crlibm is a great place to start
> for correctly-rounded elementary functions.  I think we'd need, or at
> least greatly appreciate, some help from your team.

I agree.  If crlibm can provide a solid basis for a correctly implemented
set of C99 math functions then use it.  It would be nice to have a
GCC linking exception on it though, otherwise static linking or
re-optimizing with LTO will be difficult.

Richard.

Re: weird optimization in sin+cos, x86 backend

[Vincent Lefevre]

On 2012-02-09 17:18:25 +, Joseph S. Myers wrote:
> The crlibm approach, involving exhaustive searches for worst cases for 
> directed rounding, could as I understand it work for functions of one 
> float, double or 80-bit long double argument, but I think the exhaustive 
> searches are still infeasible for binary128 (113-bit mantissa) long 
> double - although you could do functions that are probably (not proven) 
> correctly rounded in that case.  For functions of two arguments such as 
> pow, I don't know if it can produce proven correctly rounded versions even 
> for float.

For float, it might be possible to get all the hardest-to-round cases
of pow(x,y) by running my fast algorithms for each value of y. I just
fear that for large values of x and y, approximating the power function
by small-degree polynomials is very inaccurate (see below), so that my
algorithms won't work well and it may take too much time in practice.

For the double precision, even when y is restricted to an integer, this
is difficult. FYI, I currently have all the worst cases of pow(x,n) for
all positive integers n <= 3443. But for such large values of n (though
still reasonable compared to most ones in the [0,2^53] range), the
approximation of x^n by polynomials is much less accurate than for
usual functions (e.g. x^3), so that the tests run much more slowly.

> IBM long double (double+double) is a special case likely to need its own 
> implementations of many functions.  In that case it's not very 
> well-defined what correctly rounded even means (you *can* define it to be 
> the closest representable double+double value, but I doubt that's feasible 
> to implement in libm

I think you have the same kind of problems as in floating point: most
cases can be rounded "correctly" by first computing an approximation
with a bit more precision than twice the precision of double (106).
Then you have cases that are hard to round... With FP, this problem
can be solved heuristically based on probabilistic hypotheses when
they are conjectured to be satisfied, or by solving the problem in
another way for particular cases (e.g. Taylor's expansion for exp(x)
when x is close to 0). For double-double, this may be more difficult,
I think, for instance when in f(x_hi + x_lo), f(x_hi) is very close
to a rounding boundary...

Now, I don't think this is useful in practice, double-double often
being used as an intermediate arithmetic BTW.

> although it could be done for constant folding with MPFR,

Yes.

> and the basic arithmetic operations don't claim to achieve it).  

I think the goal was to have more precision than double, but still
being quite fast. The implementation of accurate elementary functions
in double precision could use such an arithmetic.

> Probably the best that's sensible is an output within a few ULP (ULPs 
> defined as if the representation is fixed-width mantissa of 106 or 107 
> bits except for subnormals)

AFAIK, considering a 106-bit precision instead of 107 (i.e. with more
redundancy) allows much faster algorithms for the basic operations.

> of the mathematical value of the function at an input within a few
> ULPs of the specified value - this may also be the best that's
> possible for other floating-point formats for some hard-to-calculate
> functions.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: weird optimization in sin+cos, x86 backend

[Vincent Lefevre]

On 2012-02-09 12:36:01 -0500, Geert Bosch wrote:
> I think it would make sense to have a check list of properties, and
> use configure-based tests to categorize implementations. These tests
> would be added as we go along.
> 
> Criteria:
> 
>  [ ] Conforms to C99 for exceptional values 
>  (accepting/producing NaNs, infinities)

C is not the only language. Other languages (e.g. Java) may have
different rules. And IEEE 754-2008 also specifies different rules.
And you may want to consider LIA-2 too, which is again different...

>  [ ] Handles non-standard rounding modes,
>  trapping math, errno, etc.

By "non-standard rounding modes", I assume you mean "non-default
rounding modes".

>  [ ] Meets certain relative error bounds,
>  copy from Ada Annex G numerical requirements
>  (typically between 2 eps and 4 eps for much of range)

FYI, OpenCL also has numerical requirements.

>  [ ] Guaranteed error less than 1 ulp over all arguments,
>  typical max. error close to 0.5 ulp.

Instead, I would say faithful rounding (this is slightly stricter
for results close to powers of 2).

>  [ ] Correctly rounded for all arguments

I would add:

   [ ] Symmetry (e.g. cos(-x) = cos(x), sin(-x) = - sin(x)) in the
   symmetric rounding modes.

   [ ] Monotonicity (for monotonous functions).

(note that they are implied by correct rounding).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: weird optimization in sin+cos, x86 backend

[Joseph S. Myers]

On Mon, 13 Feb 2012, Vincent Lefevre wrote:

> Also note that CRlibm supports the 4 rounding modes, while the
> IBM Accurate Mathematical Library currently used in glibc behaves
> erratically (e.g. can even crash) on directed rounding modes.

FWIW the proposed ISO C bindings to IEEE 754-2008 (still at an early draft 
stage) include static rounding directions set by an FENV_ROUND pragma as 
well as dynamic rounding directions.

Assuming the processor only has one set of rounding modes so arithmetic in 
a static mode requires the compiler to insert code to save and restore the 
rounding mode, the rule is that function calls to functions in math.h and 
a few other headers are affected by the static mode but other calls are 
affected by the dynamic mode so the rounding mode would need restoring for 
the other calls.  You then have the cases:

* Dynamic rounding mode in effect: user calls a function such as sin, 
which should handle the mode it is called with (maybe checking what that 
mode is, then setting the mode to round-to-nearest for most of the 
internal calculations).

* Static mode in effect: can call sin with the dynamic mode set to that 
static mode, but may be better for the compiler to select a function for 
the right mode and call it directly if it knows what the functions for 
each mode are called.

Of course right now it would make sense for the problematic functions from 
the IBM Accurate Mathematical Library to be changed to set 
round-to-nearest internally if they can't handle other modes, to make 
things less bad until a better solution can be in place

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: weird optimization in sin+cos, x86 backend

[Jakub Jelinek]

On Mon, Feb 13, 2012 at 02:48:05PM +0100, Richard Guenther wrote:
> > I think there is some consensus that crlibm is a great place to start
> > for correctly-rounded elementary functions.  I think we'd need, or at
> > least greatly appreciate, some help from your team.
> 
> I agree.  If crlibm can provide a solid basis for a correctly implemented
> set of C99 math functions then use it.  It would be nice to have a
> GCC linking exception on it though, otherwise static linking or
> re-optimizing with LTO will be difficult.

Last time I've looked, crlibm even for double provides only a subset of
functions you are looking for for the math library, so you need to take
the various *signbit*/*scal*/fpclassify*/nexttoward*/nextafter*/rint*/round*
etc. from some other source (glibc, something else).
Furthermore, crlibm_init changes the i?86/x86_64 rounding mode globally,
that is not appropriate for a general purpose math library, there you either
need to cope with extended precision, or rely on SSE/SSE2 for float/double,
or change the rounding mode dynamically on entry and reset back to previous
state in all functions that rely on it.

Jakub

Re: weird optimization in sin+cos, x86 backend

[Richard Guenther]

On Mon, Feb 13, 2012 at 3:32 PM, Jakub Jelinek  wrote:
> On Mon, Feb 13, 2012 at 02:48:05PM +0100, Richard Guenther wrote:
>> > I think there is some consensus that crlibm is a great place to start
>> > for correctly-rounded elementary functions.  I think we'd need, or at
>> > least greatly appreciate, some help from your team.
>>
>> I agree.  If crlibm can provide a solid basis for a correctly implemented
>> set of C99 math functions then use it.  It would be nice to have a
>> GCC linking exception on it though, otherwise static linking or
>> re-optimizing with LTO will be difficult.
>
> Last time I've looked, crlibm even for double provides only a subset of
> functions you are looking for for the math library, so you need to take
> the various *signbit*/*scal*/fpclassify*/nexttoward*/nextafter*/rint*/round*
> etc. from some other source (glibc, something else).

For these basic routines we could fall back to the soft-fp routines
(though I expect most targets expand those inline anyway).

> Furthermore, crlibm_init changes the i?86/x86_64 rounding mode globally,
> that is not appropriate for a general purpose math library, there you either
> need to cope with extended precision, or rely on SSE/SSE2 for float/double,
> or change the rounding mode dynamically on entry and reset back to previous
> state in all functions that rely on it.

True, we need to deal with FP state anyway for the different rounding modes
and -f[no-]rounding-math optimization.

Richard.

>        Jakub

Re: weird optimization in sin+cos, x86 backend

[Vincent Lefevre]

On 2012-02-09 15:49:37 +, Andrew Haley wrote:
> I'd start with INRIA's crlibm.

I point I'd like to correct. GNU MPFR has mainly (> 95%) been
developed by researchers and engineers paid by INRIA. But this
is not the case of CRlibm. I don't know its copyright status
(apparently, mainly ENS Lyon, and the rights have not been
transferred to the FSF).

Also, from what I've heard, CRlibm is more or less regarded as
dead, because there are new tools that do a better job, and new
functions could be generated in a few hours. I suppose a member
(not me since I don't work on these tools) or ex-member of our
team will contact some of you about this.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: weird optimization in sin+cos, x86 backend

[Vincent Lefevre]

On 2012-02-10 17:41:49 +, Andrew Haley wrote:
> On 02/10/2012 05:31 PM, Paweł Sikora wrote:
> > it would be also nice to see functions for reducing argument range in 
> > public api.
> > finally the end-user can use e.g. sin(reduce(x)) to get the best precision
> > with some declared cpu overhead.
> 
> Hmm.  I'm not sure this is such a terrific idea: each function has its
> own argument reduction (e.g. to [0, pi/4], [0, pi/8] or even [0, some
> weird constant that looks arbitrary but just happens to be exactly
> representable in binary]).  You really don't want double rounding,
> which is what would happen with sin(reduce(x)).

I agree. Also, range reduction may also be completely different.
The general scheme is:

1. Reduce the argument x (for periodic function, it is an additive
   reduction, but for some other functions, it can be a multiplicative
   reduction).

2. Compute some alternate function(s) on the reduced argument.
   For the first range reduction of periodic functions, it is the
   same function, but in other cases, this may be other functions.

3. Reconstruct the final value. Nothing to do for the first range
   reduction of periodic functions, but again, this is not always
   the case.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: weird optimization in sin+cos, x86 backend

[Joseph S. Myers]

On Mon, 13 Feb 2012, Jakub Jelinek wrote:

> Furthermore, crlibm_init changes the i?86/x86_64 rounding mode globally,
> that is not appropriate for a general purpose math library, there you either
> need to cope with extended precision, or rely on SSE/SSE2 for float/double,
> or change the rounding mode dynamically on entry and reset back to previous
> state in all functions that rely on it.

My understanding is that the crlibm method of using double+double for most 
intermediate computations, with good error bounds, triple double in cases 
where double+double isn't precise enough and searches for worst cases that 
prove triple double is always enough would work equally well using 
extended+extended for intermediate computations; you'd simply need to have 
alternative versions of the functions for use on x86 that use extended 
(80-bit) as an intermediate type.  This is of course supposing a suitable 
framework for generating functions depending on the types available for 
hardware arithmetic (similarly, you might want to generate float functions 
for x86 that also use extended as an intermediate type).

-- 
Joseph S. Myers
jos...@codesourcery.com

odd license grant in gcc(1) manpage

[Samuel Bronson]

Okay, I'm really puzzled by this. The source for gcc.1,
gcc/doc/invoke.texi, begins thus:

> @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
> @c 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
> @c Free Software Foundation, Inc.
> @c This is part of the GCC manual.
> @c For copying conditions, see the file gcc.texi.
>
> @ignore
> @c man begin INCLUDE
> @include gcc-vers.texi
> @c man end
>
> @c man begin COPYRIGHT
> Copyright @copyright{} 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
> 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
> Free Software Foundation, Inc.
>
> Permission is granted to copy, distribute and/or modify this document
> under the terms of the GNU Free Documentation License, Version 1.3 or
> any later version published by the Free Software Foundation; with the
> Invariant Sections being ``GNU General Public License'' and ``Funding
> Free Software'', the Front-Cover texts being (a) (see below), and with
> the Back-Cover Texts being (b) (see below).  A copy of the license is
> included in the gfdl(7) man page.
>
> (a) The FSF's Front-Cover Text is:
>
>     A GNU Manual
>
> (b) The FSF's Back-Cover Text is:
>
>     You have freedom to copy and modify this GNU Manual, like GNU
>     software.  Copies published by the Free Software Foundation raise
>     funds for GNU development.
> @c man end

But the @copying block in gcc.texi says:

> @copying
> Copyright @copyright{} 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997,
> 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
> 2010 Free Software Foundation, Inc.
> Permission is granted to copy, distribute and/or modify this document
> under the terms of the GNU Free Documentation License, Version 1.3 or
> any later version published by the Free Software Foundation; with the
> Invariant Sections being ``Funding Free Software'', the Front-Cover
> Texts being (a) (see below), and with the Back-Cover Texts being (b)
> (see below).  A copy of the license is included in the section entitled
> ``GNU Free Documentation License''.
>
> (a) The FSF's Front-Cover Text is:
>
>      A GNU Manual
>
> (b) The FSF's Back-Cover Text is:
>
>      You have freedom to copy and modify this GNU Manual, like GNU
>      software.  Copies published by the Free Software Foundation raise
>      funds for GNU development.
> @end copying

... Notice how the one in invoke.texi has an additional invariant
section? What's up with this?

Re: weird optimization in sin+cos, x86 backend

[Geert Bosch]

> On 2012-02-09 12:36:01 -0500, Geert Bosch wrote:
>> I think it would make sense to have a check list of properties, and
>> use configure-based tests to categorize implementations. These tests
>> would be added as we go along.
>> 
>> Criteria:
>> 
>> [ ] Conforms to C99 for exceptional values 
>> (accepting/producing NaNs, infinities)
> 
> C is not the only language. Other languages (e.g. Java) may have
> different rules. And IEEE 754-2008 also specifies different rules.
> And you may want to consider LIA-2 too, which is again different...

True, but I tried to keep the number of criteria small. Actually, 
my main interest here is allowing conformance with the Ada standard,
see chapter G.2 
(http://www.adaic.org/resources/add_content/standards/05rm/html/RM-G-2.html),
so I'm not looking at this with a "C-only" mindset. :-)

However, even though the Ada requirements are different, it would
still be tremendously helpful to be able to rely on the C99 standard,
and then just deal with other cases separately. But yes, we might
want to include even more configurability.

>> [ ] Handles non-standard rounding modes,
>> trapping math, errno, etc.
> 
> By "non-standard rounding modes", I assume you mean "non-default
> rounding modes".
Yes, indeed.
> 
>> [ ] Meets certain relative error bounds,
>> copy from Ada Annex G numerical requirements
>> (typically between 2 eps and 4 eps for much of range)
> 
> FYI, OpenCL also has numerical requirements.
They seem similar, though only apply to single precision,
while the rules defined by Ada are parametrized by type.
Where OpenCL specifies an error as 4 ulps, Ada specifies a
relative error of 2 epsilon. For values just below a
power of 2, 2 epsilon equals 4 ulps, while for values 
just above they are ulps and eps are equivalent.
So, the Ada requirements are a bit tighter in general.
Probably we can define something that is the union
of both sets of requirements. 

>> [ ] Guaranteed error less than 1 ulp over all arguments,
>> typical max. error close to 0.5 ulp.
> 
> Instead, I would say faithful rounding (this is slightly stricter
> for results close to powers of 2).
Yes, that is better.
> 
>> [ ] Correctly rounded for all arguments
> 
> I would add:
> 
>   [ ] Symmetry (e.g. cos(-x) = cos(x), sin(-x) = - sin(x)) in the
>   symmetric rounding modes.
> 
>   [ ] Monotonicity (for monotonous functions).
> 
> (note that they are implied by correct rounding).
Right, my goal was to have just a few different buckets that fit
well with GCC compilation options and allow categorization of 
existing functions. 

I guess, it should be a few check boxes and a numerical level.
This would be a categorization for source code, not compiled
code where me might have additional copies based on optimization
(size/latency/throughput/vectorization).

Properties:

  [ ]  Conforms to C99 for exceptional values 
   (accepting/producing NaNs, infinities)

  [ ]  Handles non-default rounding modes,
   trapping math, errno, etc.

  [ ]  Requires IEEE compliant binary64 arithmetic
   (no implicit extended range or precision)

  [ ]  Requires IEEE compliant binary80 arithmetic
   (I know, not official format, but YKWIM)
 
Accuracy level:

  0 - Correctly rounded

  1 - Faithfully rounded, preserving symmetry and monotonicity

  2 - Tightly approximated, meeting prescribed relative error
  bounds. Conforming to OpenCL and Ada Annex G "strict mode"
  numerical bounds.

  3 - Unspecified error bounds

Note that currently of all different operating systems we (AdaCore)
support for the GNAT compiler, I don't know of any where we can rely
on the system math library to meet level 2 requirements for all
functions and over all of the range! Much of this is due to us 
supporting OS versions as long as there is vendor support, so while 
SPARC Solaris 9 and later are fine, Solaris 8 had some issues. 
GNU Linux is quite good, but has issues with the "pow" function for
large exponents, even in current versions, and even though Ada
allows a relative error of (4.0 + |Right · log(Left)| / 32.0) 
for this function, or up to 310 ulps at the end of the range.
Similarly, for trigonometric functions, the relative error for 
arguments larger than some implementation-defined angle threshold
is not specified, though the angle threshold needs to be at
least radix**(mantissa bits / 2), so 2.0**12 for binary32 or 2.0**32
for binary80. OpenCL doesn't specify an angle threshold, but I
doubt they intend to require sufficient accurate reduction over
the entire range to have a final error of 4 ulps: that doesn't fit
with the rest of the requirements.

The Ada test suite (ACATS) already has quite extensive tests for (2),
which are automatically parameterized for any type (including those
with non-binary radix). That, and the fact that this level apparently
is still a challenge for most system math libraries seems like a good
reason for aiming for this level as a base level.

We should con

Re: odd license grant in gcc(1) manpage

[Joseph S. Myers]

On Mon, 13 Feb 2012, Samuel Bronson wrote:

> ... Notice how the one in invoke.texi has an additional invariant
> section? What's up with this?

It looks like Ralf's 2008-07-30 commit (r138293) omitted to change 
invoke.texi.

-- 
Joseph S. Myers
jos...@codesourcery.com

symbol_refs vs. eq_attr in define_insn_reservations

[Quentin Neill]

Hi,

For readability (and correctness) I'm interested in rewriting a bunch of:

  (define_insn_reservation "insn1" 0 (eq_attr "attr1" "val1,val2"))

into something like:

  (define attr "consattr1" "val1,val2"
(const (cond [
  (eq_attr "attr1" "val1") (const_string "cvaly")
  (eq_attr "attr1" "val2") (const_string "cvaly")]
(const_string "cvaln"

  (define_insn_reservation "insn1" 0 (eq_attr "consattr1" "cval"))

But then in 
http://gcc.gnu.org/onlinedocs/gccint/Constant-Attributes.html#Constant-Attributes
we find:

"RTL expressions used to define the value of a constant attribute
may use the symbol_ref form, but may not use either the match_operand
form or eq_attr forms involving insn attributes."

Does that restriction also apply to the regexp part of
(define_insn_reservation ...) statements?

Or do I need to do something like:

  (define_insn_reservation "insn1" 0 (..some expression using symbol_ref))

I couldn't find any examples of symbol_ref using constants - only C
code or functions, so if I do need to use a symbol_ref with a
constant, what would it look like?

-- 
Quentin