On 6/19/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply
> 'wrong', not inaccurate ;)
I still support the introduction of a special switch for this kind of
transformation, -fwrong-math-optimizations. :-)
Probably as useful
OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply
'wrong', not inaccurate ;)
I still support the introduction of a special switch for this kind of
transformation, -fwrong-math-optimizations. :-)
Paolo
On 6/18/07, Brooks Moses <[EMAIL PROTECTED]> wrote:
Giovanni Bajo wrote:
> Both our goals are legitimate. But that's not the point. The point is
> what -ffast-math semantically means (the simplistic list of suboptions
> activated by it is of couse unsufficiente because it doesn't explain how
> to
On 6/19/07, tbp <[EMAIL PROTECTED]> wrote:
Indeed there are holes in every direction when you pull in such
transformation, and the cost of plugging every one of them would be
prohibitive; the next batch of c2d supposedly will leave you with ~6
cycles to make it worth for a sqrt.
My C2D has 6 c
Bradley Lucier wrote:
> If -ffinite-math-only is specified, then producing NaN instead of inf
> should be allowed.
Agreed. After all, -finite-math says:
Allow optimizations for floating-point arithmetic that assume that
arguments and results are not NaNs or +-Infs.
Since the compiler
On 6/18/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
IMO, due to limited range of operands for -mrecip pass (inf, -inf);
where 0.0 is excluded, it should be keept out of -ffast-math. There is
no point to fix reciprocals only for 0.0, we need to fix both
conversions for infinity and 0.0, even in -f
On Jun 18, 2007, at 2:27 PM, Bradley Lucier wrote:
But even if sqrt is corrected for 0.0 * inf, there would still be
a lot of problems with the combinations of NR-enhanced rsqrt and
rcp. Consider for example:
1.0/sqrt(a/b) alias rsqrt(a/b)
Having a=0, b != 0, the result is inf.
As alrea
On Jun 18, 2007, at 2:14 PM, Uros Bizjak wrote:
tbp wrote:
For example, when doing 1/x and sqrt(x) via reciprocal + NR, you
first
get an inf from said reciprocal which then turns to a NaN in the NR
stage but if you correct it by, say, doing a comparison to 0 and a
'and'.
That's what ICC us
Giovanni Bajo wrote:
Both our goals are legitimate. But that's not the point. The point is
what -ffast-math semantically means (the simplistic list of suboptions
activated by it is of couse unsufficiente because it doesn't explain how
to behave in face of new options, like -mrecip). My proposal
tbp wrote:
For example, when doing 1/x and sqrt(x) via reciprocal + NR, you first
get an inf from said reciprocal which then turns to a NaN in the NR
stage but if you correct it by, say, doing a comparison to 0 and a
'and'.
That's what ICC used to do in your back. That's what you'll find page
15
On 6/18/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
I understand your problems, but let me state that your objections are
totally subjective. *You* need a specific behaviour from -ffast-math
(eg: keep NaN/Inf), but that's not what *I* need. So, we have different
goals.
No. My NaN are my problem
On 6/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
No, that's not the contract with -ffast-math. Note that -ffast-math
enables -funsafe-math-optimizations which is allowed to change results
(add/remove rounding operations, contract expressions, do transforms
like a/b to a * 1/b, do transfor
On 6/18/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
On 6/18/07, tbp <[EMAIL PROTECTED]> wrote:
> Until now, the contract was: you have to deal with (and contain) NaN
> and infinities. Fair enough, even if tricky that remained manageable.
> But if i can't expect a mere division by 0, or sqrt of 0
On 6/18/2007 12:16 PM, tbp wrote:
Of course there are cases with every optimization enabled by
-ffast-math that
can break existing programs. Just that we know of one case beforehand
shouldn't
prevent us from enabling -mrecip at -ffast-math (provided -mno-recip
still works,
regardless if provi
On 6/18/07, tbp <[EMAIL PROTECTED]> wrote:
Until now, the contract was: you have to deal with (and contain) NaN
and infinities. Fair enough, even if tricky that remained manageable.
But if i can't expect a mere division by 0, or sqrt of 0 (quite common
with FTZ/DAZ on) to give me respectively an
On 6/18/07, tbp <[EMAIL PROTECTED]> wrote:
On 6/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> Of course there are cases with every optimization enabled by -ffast-math that
> can break existing programs. Just that we know of one case beforehand
shouldn't
> prevent us from enabling -mrecip
On 6/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
Of course there are cases with every optimization enabled by -ffast-math that
can break existing programs. Just that we know of one case beforehand shouldn't
prevent us from enabling -mrecip at -ffast-math (provided -mno-recip
still works,
On 6/17/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
Hello!
> I was wondering if there are objects to automatically activating Uros'
> new -mrecip flag when -ffast-math is specified. It looks like a good
> match since -mrecip is exactly about fast non-precise mathematics.
There is a discussion in
On 17/06/2007 20.20, Uros Bizjak wrote:
I was wondering if there are objects to automatically activating Uros'
new -mrecip flag when -ffast-math is specified. It looks like a good
match since -mrecip is exactly about fast non-precise mathematics.
There is a discussion in gcc-patches@ mailing
Hello!
I was wondering if there are objects to automatically activating Uros'
new -mrecip flag when -ffast-math is specified. It looks like a good
match since -mrecip is exactly about fast non-precise mathematics.
There is a discussion in gcc-patches@ mailing list about this topic, in
"Re: [
Hello,
I was wondering if there are objects to automatically activating Uros' new
-mrecip flag when -ffast-math is specified. It looks like a good match since
-mrecip is exactly about fast non-precise mathematics.
--
Giovanni Bajo
21 matches
Mail list logo