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
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/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 and
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 (quite
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
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.
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
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
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
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
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
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/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 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/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 at
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
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
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:
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
19 matches
Mail list logo
