FE Exception triggered by comparison

FE Exception triggered by comparison

[Damian McGuckin]

What comparison of FP numbers trigger invalid operation exceptions?

Does a comparison like

 	if (x != x)
 	{
 		/* get to here if x == NaN *
 	}

which tests for a NaN cause an invalid operation if given an sNaN?

Even reading the standard numerous times and I am not any wiser.

Thanks - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: FE Exception triggered by comparison

[Markus Wichmann]

On Mon, Feb 25, 2019 at 12:28:20AM +1100, Damian McGuckin wrote:
> 
> What comparison of FP numbers trigger invalid operation exceptions?
> 
> Does a comparison like
> 
> 	if (x != x)
> 	{
> 		/* get to here if x == NaN *
> 	}
> 
> which tests for a NaN cause an invalid operation if given an sNaN?
> 
> Even reading the standard numerous times and I am not any wiser.
> 
> Thanks - Damian
> 

In cases like these, I like to read the documentation of an
implementation, under the assumption that it is conforming. One
implementation of IEE 754 general considered to be conforming is the x87
instruction set. And AMD's documentation of the same (AMD64 Architecture
Programmer's Manual, Volume 5, Order No. 26569) says about the FCOM
instruction, that it will generate an invalid-operation exception if any
source operand was a NaN. Same for FCOMI and FICOM.

Only difference for FUCOM and FUCOMI is that those only raise IE for an
SNaN.

Cross-checking with volume 4 shows that the SSE FP compare instructions
all raise IE in case of SNan source operand, and in case of "Undefined
operation". No idea what the latter is supposed to mean in context,
unless it means that QNaNs trigger it, too.

So yes, it appears at least in a PC, comparison with NaN raises IE.

Ciao,
Markus

Re: FE Exception triggered by comparison

[Szabolcs Nagy]

* Damian McGuckin <damianm@esi.com.au> [2019-02-25 00:28:20 +1100]:
> What comparison of FP numbers trigger invalid operation exceptions?
> 
> Does a comparison like
> 
> 	if (x != x)
> 	{
> 		/* get to here if x == NaN *
> 	}
> 
> which tests for a NaN cause an invalid operation if given an sNaN?

iso c does not say much about sNaN: a conforming implementation
does not have to support sNaN (it is usually treated as qNaN,
with unspecified signaling behaviour and you need special
compiler options to ensure sNaN breaking transformations are
not done if you want to rely on sNaN signals)

with c99 annex F, c == and != operators are mapped to ieee 754
compareQuiet{Not}Equal, which is non-signaling with qNaN inputs
but signals invalid with sNaN inputs, so in practice sNaN != sNaN
will signal in c.

> Even reading the standard numerous times and I am not any wiser.

i think it's better to look at the ieee 754 spec instead
of the c spec, drafts are at http://754r.ucbtest.org/drafts/

annex F.3 describes how c is mapped to ieee 754 (iec 60559
is supposed to be very close to ieee 754).

ts 18661-* provides more detailed description of the mapping
to ieee 754-2008 (it will likely be part of c2x and it is a
bit more strict than what iso c currently allows).

Re: FE Exception triggered by comparison

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 2644 bytes --]

Hello,

On Sun, 24 Feb 2019 20:25:11 +0100 Szabolcs Nagy <nsz@port70.net> wrote:

> * Damian McGuckin <damianm@esi.com.au> [2019-02-25 00:28:20 +1100]:
> > What comparison of FP numbers trigger invalid operation exceptions?
> > 
> > Does a comparison like
> > 
> > 	if (x != x)
> > 	{
> > 		/* get to here if x == NaN *
> > 	}
> > 
> > which tests for a NaN cause an invalid operation if given an sNaN?  
> 
> iso c does not say much about sNaN: a conforming implementation
> does not have to support sNaN (it is usually treated as qNaN,
> with unspecified signaling behaviour and you need special
> compiler options to ensure sNaN breaking transformations are
> not done if you want to rely on sNaN signals)
> 
> with c99 annex F, c == and != operators are mapped to ieee 754
> compareQuiet{Not}Equal, which is non-signaling with qNaN inputs
> but signals invalid with sNaN inputs, so in practice sNaN != sNaN
> will signal in c.
> 
> > Even reading the standard numerous times and I am not any wiser.  
> 
> i think it's better to look at the ieee 754 spec instead
> of the c spec, drafts are at http://754r.ucbtest.org/drafts/
> 
> annex F.3 describes how c is mapped to ieee 754 (iec 60559
> is supposed to be very close to ieee 754).
> 
> ts 18661-* provides more detailed description of the mapping
> to ieee 754-2008 (it will likely be part of c2x and it is a
> bit more strict than what iso c currently allows).

Yes, we are currently integrating parts 1 and 2 of this TS into the
standard. Usually you should be able to see a first version of that in
a few weeks in the pre-London mailing.

For the moment they are integrated "as such" that is with "WANT"
macros that make these "new" interfaces optional. Further in the
process I hope that we will be able to do a bit more:

   - Remove this "optionality" from the numbered clauses and make all
     interfaces mandatory.

   - Some naming changes while these are not too fixed in peoples
     minds. Only very few identifiers in <math.h> are reserved for
     future use, so adding new interfaces will necessarily step on
     someones shoes.

   - Add some version macros for the different header files, such that
     applications and implementors have better chances to adapt during
     the time of transition.

Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: FE Exception triggered by comparison

[Damian McGuckin]

Hi Markus, Jens,

Thanks for the replies.

On Sun, 24 Feb 2019, Jens Gustedt wrote:

>> with c99 annex F, c == and != operators are mapped to ieee 754
>> compareQuiet{Not}Equal, which is non-signaling with qNaN inputs
>> but signals invalid with sNaN inputs, so in practice sNaN != sNaN
>> will signal in c.

I guess I am still trying to figure out where/when sNaN will appear so I 
can code defensively to protect my code. The C interface like 'isless' and 
friends are really woeful performers.

>> i think it's better to look at the ieee 754 spec instead
>> of the c spec, drafts are at http://754r.ucbtest.org/drafts/

I agree. But while I found the 1985 standard readable and clear, all the 
subsequent revisions have sections, especially related to exceptions, that 
are difficult to comprehend. And I thought I spoke English. The language 
is convoluted.

> Yes, we are currently integrating parts 1 and 2 of this TS into the
> standard. Usually you should be able to see a first version of that in
> a few weeks in the pre-London mailing.

Thanks.

> For the moment they are integrated "as such" that is with "WANT"
> macros that make these "new" interfaces optional.

Hmmm. Scary. I

The context of this is that I want a coding style which means I can 
compare numbers without affecting the exception state. And it must have 
zero overhead, and not affect the readability of the code, i.e. no 
function calls.

I want to know that

 	x != x

will always detect any NaN with affecting the exception status and that
comparisons like

 	if (x == x) { ... }
 	else if (x > y) { .... }
 	else if (x < y) { .... }
 	else { x or y are NaN }

will similarly also not modify the exception status, and in the last 
section let me process how I interpret the NaNs.

Otherwise, avoidance of creating spurious exceptions forces you to start 
working at the IEEE 754 encoding level. This is counterproductive to clear 
and concise programming. Such a style is riddled through a lot of the 
maths routines in MUSL and the libraries that came before it. It also 
means that all these magic constants start to appear in the code, severely 
affecting comprehensibility. Any generic coding style is just stopped in 
its tracks.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: FE Exception triggered by comparison

[Damian McGuckin]

On Mon, 25 Feb 2019, Damian McGuckin wrote:

> comparisons like
>
> 	 if (x == x) { ... }

Sorry, typo. I should have been written this as

 	if (x == y) { ... }

and the rest is OK.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: FE Exception triggered by comparison

[Markus Wichmann]

On Mon, Feb 25, 2019 at 08:50:52AM +1100, Damian McGuckin wrote:
> The context of this is that I want a coding style which means I can compare
> numbers without affecting the exception state. And it must have zero
> overhead, and not affect the readability of the code, i.e. no function
> calls.
> 

Yet another problem brought to you by premature optimization. What you
want to know is if a certain number is NaN. There's a perfectly
acceptable idiom for that:

if (isnan(x)) {
}

This (the exception stuff) is the reason why the special cases are
always front-loaded in musl. So they can be sorted out without raising
spurious exceptions.

The only reason the above may not be acceptable to you is that it looks
like a function call. But it isn't. isnan() is a macro that doesn't
always revert to a function call.

> I want to know that
> 
> 	x != x
> 
> will always detect any NaN with affecting the exception status and that
> comparisons like
> 
> 	if (x == x) { ... }
> 	else if (x > y) { .... }
> 	else if (x < y) { .... }
> 	else { x or y are NaN }
> 
> will similarly also not modify the exception status, and in the last section
> let me process how I interpret the NaNs.
> 

Well, sorry, but these instructions do not work that way. Any operation
on a NaN, including comparison, even comparison for equality, will raise
IE, at least if it is an sNaN.

Honestly, though, I wonder what the big deal is. In most cases, if you
see a NaN, someone probably just made an invalid operation, or chose to
start another invalid operation with your function. In which case
raising IE is not spurious at all.

> Otherwise, avoidance of creating spurious exceptions forces you to start
> working at the IEEE 754 encoding level.

Or you could just use the interface provided by the C standard:

if (!isnormal(x) || !isnormal(y)) {
    guard clause here;
    return;
}
/* definitely normal x and y from this point on. */

Hopefully you don't need to deal with subnormals...

> This is counterproductive to clear
> and concise programming. Such a style is riddled through a lot of the maths
> routines in MUSL and the libraries that came before it.

No, that's just an optimization. Musl strives to minimize the numeric
error while also delivering good performance, and that means that often
a lot of boundary conditions can be detected at the same time with a
single comparison (e.g. you can detect "x < 0 || x > 2**limit ||
isinf(x)" by detecting if the exponent and sign bit together exceed a
certain limit.)

But nothing is stopping you from writing these conditions out entirely.

Ciao,
Markus

Re: FE Exception triggered by comparison

[Damian McGuckin]

Hi Markus,

Thanks for taking the time to reply in depth.

Where I am coming from is some research writing low level routines for a 
language other than C/C++, learning lessons from that, and then wanting to 
contribute that back some of what I have learnt in a fashion that can be 
used in MUSL. The metrics/goals/style in that other programming language 
are somewhat different to MUSL so I only want to give back what integrates 
well into MUSL's metrics/goals/style. That way, I do not waste anyone's 
time.

On Mon, 25 Feb 2019, Markus Wichmann wrote:

> On Mon, Feb 25, 2019 at 08:50:52AM +1100, Damian McGuckin wrote:

>> The context of this is that I want a coding style which means I can 
>> compare numbers without affecting the exception state. And it must have 
>> zero overhead, and not affect the readability of the code, i.e. no 
>> function calls.
>
> Yet another problem brought to you by premature optimization. What you
> want to know is if a certain number is NaN. There's a perfectly
> acceptable idiom for that:
>
> if (isnan(x)) {
> }

I understand this. But, at least on an X86 architecture, that involves a 
write-to+read-from memory and I want to avoid that.

> This (the exception stuff) is the reason why the special cases are
> always front-loaded in musl. So they can be sorted out without raising
> spurious exceptions.

Front-loading often results in more lines of code and regularly, less 
lines of code means faster execution so with careful avoidance of the 
front-loading is feasible, I prefer it.

> The only reason the above may not be acceptable to you is that it looks
> like a function call. But it isn't. isnan() is a macro that doesn't
> always revert to a function call.

All of the fpclassify() and friends routines are quite heavy, even if they 
are macros and are done in line so I avoid them. That is just my opinion. 
Do I have a better solution for usage by the masses - No, well not in 
C/C++. See my later comments on builtins.

>> I want to know that
>>
>> 	x != x
>>
>> will always detect any NaN with affecting the exception status and that
>> comparisons like
>>
>> 	if (x == x) { ... }
>> 	else if (x > y) { .... }
>> 	else if (x < y) { .... }
>> 	else { x or y are NaN }
>>
>> will similarly also not modify the exception status, and in the last 
>> section let me process how I interpret the NaNs.

> Well, sorry, but these instructions do not work that way. Any operation
> on a NaN, including comparison, even comparison for equality, will raise
> IE, at least if it is an sNaN.

Table 5.1 of the 20X8 standard, as I read it, and as confirmed by Kahan's 
lecture notes, says that neither equality nor inequality is supposed to 
raise an IE on a qNaN. As you rightly say, Kahan's lecture notes, the 1985 
standard and Table 5.2 in the 2008 and the 2018(draft) standards says that 
any comparison with a '<' or '>' as part (or all) of the predicate should 
raise IE.

However, on experiments on GCC, the if/else/else/else above does not raise 
an IE. Is this an optimizer bug? For a while there, I questioned my whole 
understanding of the standard in terms of comparison until I went back to 
it and re-read it. Something is weird with GCC. And either you or I has 
the wrong understanding of what Table 5.1 implies for both an equality and 
an inequality comparison. And at least mine agrees with Kahan's lecture 
notes. It is not the latest GCC but one that I, and clients, need to use.

Note that if I manually create an sNaN and use it in the comparisons, then 
GCC behaves as the standard says. I wish I knew what creates an sNaN. The
only optimization I use is -O3.

> Honestly, though, I wonder what the big deal is. In most cases, if you 
> see a NaN, someone probably just made an invalid operation, or chose to 
> start another invalid operation with your function. In which case 
> raising IE is not spurious at all.

I agree that in most cases it is not a big deal. And the raising of an IE 
is not spurious in most cases. But there are cases where it is. I tried to 
rewrite frexp so it can be done in line but I get an IE which is a no-no 
for this routine. I know that frexp is supposed to be builtin in GCC/G++ 
but I kept seeing the function call in the assembler so I have no idea why 
GCC says it is builtin. Hence my original reason for doing frexp.

>> Otherwise, avoidance of creating spurious exceptions forces you to 
>> start working at the IEEE 754 encoding level.
>
> Or you could just use the interface provided by the C standard:
>
> if (!isnormal(x) || !isnormal(y)) {
>    guard clause here;
>    return;
> }

Again, memory access is the killer. Also, there is a lot of duplication in 
those macros that does not always get optimized away unless you rely on a 
built-in. And I try and stay away from things that one or another compiler 
thinks is a built-in.

I do need to deal with subnormals but I can handle that. Besides, any 
comparison of subnormals does not trigger an exception unless there are 
arithmetic expressions as either a LHS or RHS of the comparison operator. 
Mind you, I once saw some code where it looks like the author did think 
that an underflow exception got triggered during the comparison of a 
possibly subnormal number against a constant which was not subnormal.

> Musl strives to minimize the numeric error while also delivering good 
> performance, and that means that often a lot of boundary conditions can 
> be detected at the same time with a single comparison (e.g. you can 
> detect "x < 0 || x > 2**limit || isinf(x)" by detecting if the exponent 
> and sign bit together exceed a certain limit.)

What MUSL's strives to do is indeed what I also seek. That said, I have 
found that you often get less lines of code and better performance if you 
can postpone the inspection of the IEEE 754 encoding as late as possible 
within a routine. It is only at that point do you think about extracting 
the exponent and sign cheaply.

Just my 2c.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: FE Exception triggered by comparison

[Alexander Monakov]

On Tue, 26 Feb 2019, Damian McGuckin wrote:

> > Yet another problem brought to you by premature optimization. What you
> > want to know is if a certain number is NaN. There's a perfectly
> > acceptable idiom for that:
> > 
> > if (isnan(x)) {
> > }
> 
> I understand this. But, at least on an X86 architecture, that involves a
> write-to+read-from memory and I want to avoid that.

I don't understand this claim.  With both SSE and x87 this should amount to
comparing a register with itself and testing flags.  Can you elaborate?

> > Well, sorry, but these instructions do not work that way. Any operation
> > on a NaN, including comparison, even comparison for equality, will raise
> > IE, at least if it is an sNaN.

(for sNaNs, sure, but notably for qNaNs comparisons for equality, as opposed
to ordered comparisons, should not raise "invalid" in C and C++)

> However, on experiments on GCC, the if/else/else/else above does not raise an
> IE. Is this an optimizer bug?

You're probably seeing the long-standing bug in gcc x86 backend where it would
emit 'ucom'-kind instructions for both ordered and equality comparisons.  It
appears to be finally fixed starting from GCC 8.

Alexander

Re: FE Exception triggered by comparison

[Damian McGuckin]

On Wed, 27 Feb 2019, Alexander Monakov wrote:

>> I understand this. But, at least on an X86 architecture, that involves 
>> a write-to+read-from memory and I want to avoid that.
>
> I don't understand this claim.  With both SSE and x87 this should amount 
> to comparing a register with itself and testing flags.  Can you 
> elaborate?

I would love to be proved wrong, but if you want something that is safe 
from generating an exception with an signalling NaN, you need to do this.

For qNaN stuff, I personally normally do

 	if (x != x) /* then 'x' is an NaN */

but I find that isnan(x) does not expand to anything like this.  Anyway, 
when I tried the code below, I was just shocked.

 	#include	<math.h>
 	#include	<stdio.h>

 	main()
 	{
 		double x = 5.0;

 		x -= x, x /= x;
 		printf("what %s\n", isnan(x) ? "yes" : "no!");
 		return(0);
 	}

Looking at the assembler, there is a subroutine call to __isnan. Awful!

>>> Well, sorry, but these instructions do not work that way. Any 
>>> operation on a NaN, including comparison, even comparison for 
>>> equality, will raise IE, at least if it is an sNaN.
>
> (for sNaNs, sure, but notably for qNaNs comparisons for equality, as 
> opposed to ordered comparisons, should not raise "invalid" in C and C++)

You are correct. Markus was reading the standard incorrectly I believe. Or 
maybe my explanation of what I was trying to do was poor and Markus simply
misunderstood what I was trying to say!

>> However, on experiments on GCC, the if/else/else/else above does not 
>> raise an IE. Is this an optimizer bug?
>
> You're probably seeing the long-standing bug in gcc x86 backend where it 
> would emit 'ucom'-kind instructions for both ordered and equality 
> comparisons.  It appears to be finally fixed starting from GCC 8.

Wonderful. Thanks for that information. GCC 8 is on my list of updates but 
I have yet to get around to it. I will rerun my tests against that.

I do lament that I have to resort to using

 	isless()

macro and friends to do a comparison in C/C++ without triggering an IE. It 
really does seriously compromise the readability of code. It would be nice 
if we had operators like

 	~<=

instead of having to use the long-winded

 	islessequal

Than again, everybody wants their own succint operators and there are only 
a limited number of characters to exploit. I think Professor Kahan asked 
for
 	!<

for 'not less than' over 20 years ago and we have not seen any movement
on that front.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: FE Exception triggered by comparison

[Alexander Monakov]

On Thu, 28 Feb 2019, Damian McGuckin wrote:

> I tried the code below, I was just shocked.
> 
> 	#include	<math.h>
> 	#include	<stdio.h>
> 
> 	main()
> 	{
> 		double x = 5.0;
> 
> 		x -= x, x /= x;
> 		printf("what %s\n", isnan(x) ? "yes" : "no!");
> 		return(0);
> 	}
> 
> Looking at the assembler, there is a subroutine call to __isnan. Awful!

Hm, no, for x86 with GCC you should not see that: the compiler knows how
to expand isnan efficiently.  Are you perhaps on OS X and the 'gcc' command
actually invokes Clang/LLVM?  If not, can you show output of 'gcc -v',
command-line flags you used, and the assembly you're seeing?

Thanks.
Alexander

Re: FE Exception triggered by comparison

[Damian McGuckin]

Thanks for the feedback.

On Wed, 27 Feb 2019, Alexander Monakov wrote:

> On Thu, 28 Feb 2019, Damian McGuckin wrote:
>
>> I tried the code below, I was just shocked.
>>
>> 	#include	<math.h>
>> 	#include	<stdio.h>
>>
>> 	main()
>> 	{
>> 		double x = 5.0;
>>
>> 		x -= x, x /= x;
>> 		printf("what %s\n", isnan(x) ? "yes" : "no!");
>> 		return(0);
>> 	}
>>
>> Looking at the assembler, there is a subroutine call to __isnan. Awful!
>
> Hm, no, for x86 with GCC you should not see that: the compiler knows how 
> to expand isnan efficiently.  Are you perhaps on OS X and the 'gcc' 
> command actually invokes Clang/LLVM?

No.

> If not, can you show output of 'gcc -v', command-line flags you used, 
> and the assembly you're seeing?

 	gcc -O3 -S -msse4.2 -mfma mynan.c

Here is the assembler:

 	.file	"mynan.c"
 	.section	.rodata.str1.1,"aMS",@progbits,1
.LC0:
 	.string	"yes"
.LC1:
 	.string	"no!"
.LC3:
 	.string	"what %s\n"
 	.section	.text.startup,"ax",@progbits
 	.p2align 4,,15
 	.globl	main
 	.type	main, @function
main:
.LFB14:
 	.cfi_startproc
 	vxorpd	%xmm0, %xmm0, %xmm0
 	subq	$8, %rsp
 	.cfi_def_cfa_offset 16
 	vdivsd	%xmm0, %xmm0, %xmm0
 	call	__isnan
 	movl	$.LC0, %esi
 	testl	%eax, %eax
 	movl	$.LC1, %eax
 	cmove	%rax, %rsi
 	movl	$.LC3, %edi
 	xorl	%eax, %eax
 	call	printf
 	xorl	%eax, %eax
 	addq	$8, %rsp
 	.cfi_def_cfa_offset 8
 	ret
 	.cfi_endproc
.LFE14:
 	.size	main, .-main
 	.ident	"GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-36)"
 	.section	.note.GNU-stack,"",@progbits

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: FE Exception triggered by comparison

[Markus Wichmann]

On Thu, Feb 28, 2019 at 03:09:54AM +1100, Damian McGuckin wrote:
> 	.ident	"GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-36)"

You might want to consider upgrading:

	.file	"nan.c"
	.text
	.section	.rodata.str1.1,"aMS",@progbits,1
.LC0:
	.string	"yes"
.LC1:
	.string	"no!"
.LC3:
	.string	"what %s\n"
	.section	.text.startup,"ax",@progbits
	.p2align 4,,15
	.globl	main
	.type	main, @function
main:
.LFB17:
	.cfi_startproc
	pxor	%xmm0, %xmm0
	subq	$8, %rsp
	.cfi_def_cfa_offset 16
	movabsq	$9218868437227405312, %rdx
	divsd	%xmm0, %xmm0
	leaq	.LC0(%rip), %rsi
	leaq	.LC3(%rip), %rdi
	movq	%xmm0, %rax
	btrq	$63, %rax
	cmpq	%rdx, %rax
	leaq	.LC1(%rip), %rax
	cmovbe	%rax, %rsi
	xorl	%eax, %eax
	call	printf@PLT
	xorl	%eax, %eax
	addq	$8, %rsp
	.cfi_def_cfa_offset 8
	ret
	.cfi_endproc
.LFE17:
	.size	main, .-main
	.ident	"GCC: (Debian 8.2.0-14) 8.2.0"
	.section	.note.GNU-stack,"",@progbits

That sufficiently efficient for you?

Ciao,
Markus

Re: FE Exception triggered by comparison

[Damian McGuckin]

On Wed, 27 Feb 2019, Markus Wichmann wrote:

> That sufficiently efficient for you?

Yes.

Thanks - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: FE Exception triggered by comparison

[Damian McGuckin]

On Wed, 27 Feb 2019, Markus Wichmann wrote:

> On Thu, Feb 28, 2019 at 03:09:54AM +1100, Damian McGuckin wrote:
>> 	.ident	"GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-36)"
>
> You might want to consider upgrading:

Done. But the subroutine call is still hanging around. What am I doing 
wrong.

Yours is:

> 	.globl	main
> 	.type	main, @function
> main:
> .LFB17:
> 	.cfi_startproc
> 	pxor	%xmm0, %xmm0
> 	subq	$8, %rsp
> 	.cfi_def_cfa_offset 16
> 	movabsq	$9218868437227405312, %rdx
> 	divsd	%xmm0, %xmm0
> 	leaq	.LC0(%rip), %rsi
> 	leaq	.LC3(%rip), %rdi
> 	movq	%xmm0, %rax
> 	btrq	$63, %rax
> 	cmpq	%rdx, %rax
> 	leaq	.LC1(%rip), %rax
> 	cmovbe	%rax, %rsi
> 	xorl	%eax, %eax
> 	call	printf@PLT
> 	xorl	%eax, %eax
> 	addq	$8, %rsp
> 	.cfi_def_cfa_offset 8
> 	ret
> 	.cfi_endproc
> .LFE17:
> 	.size	main, .-main
> 	.ident	"GCC: (Debian 8.2.0-14) 8.2.0"
> 	.section	.note.GNU-stack,"",@progbits
>
> That sufficiently efficient for you?

It would be if I could achieve it.  What options do I need? I use

 	gcc -S -O3 -msse4.2 -mfma mynan.c

See below:

 	.file	"mynan.c"
 	.text
 	.section	.rodata.str1.1,"aMS",@progbits,1
.LC0:
 	.string	"yes"
.LC1:
 	.string	"no!"
.LC3:
 	.string	"what %s\n"
 	.section	.text.startup,"ax",@progbits
 	.p2align 4,,15
 	.globl	main
 	.type	main, @function
main:
.LFB14:
 	.cfi_startproc
 	vxorpd	%xmm0, %xmm0, %xmm0
 	subq	$8, %rsp
 	.cfi_def_cfa_offset 16
 	vdivsd	%xmm0, %xmm0, %xmm0
 	call	__isnan
 	movl	$.LC0, %esi
 	movl	$.LC3, %edi
 	testl	%eax, %eax
 	movl	$.LC1, %eax
 	cmove	%rax, %rsi
 	xorl	%eax, %eax
 	call	printf
 	xorl	%eax, %eax
 	addq	$8, %rsp
 	.cfi_def_cfa_offset 8
 	ret
 	.cfi_endproc
.LFE14:
 	.size	main, .-main
 	.ident	"GCC: (GNU) 8.2.1 20180905 (Red Hat 8.2.1-3)"
 	.section	.note.GNU-stack,"",@progbits

It is the standard package with devtools-8 under CentOS.

Thanks - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: FE Exception triggered by comparison

[Rich Felker]

On Thu, Feb 28, 2019 at 12:07:36PM +1100, Damian McGuckin wrote:
> On Wed, 27 Feb 2019, Markus Wichmann wrote:
> 
> >On Thu, Feb 28, 2019 at 03:09:54AM +1100, Damian McGuckin wrote:
> >>	.ident	"GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-36)"
> >
> >You might want to consider upgrading:
> 
> Done. But the subroutine call is still hanging around. What am I
> doing wrong.

It's an old glibc, not an old gcc, causing this.

Rich

Re: FE Exception triggered by comparison

[Damian McGuckin]

On Wed, 27 Feb 2019, Rich Felker wrote:

>> Done. But the subroutine call is still hanging around. What am I
>> doing wrong.
>
> It's an old glibc, not an old gcc, causing this.

Don't worry. With MUSL's definitions, it is all in-line.

Not really interested in GLIBC. I was just reverting to vanilla stuff for 
my testing in case I was doing stupid things with MUSL, ....

And Alexander was right, I was being stabbed in the back by GCC with its
use of UCOM... rather than COM.... That just added to my confusion. I also 
move back and forth between Chapel and C/C++ which further scrambles the 
thought processes.

All sorted. Thanks - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: FE Exception triggered by comparison

[Alexander Monakov]

On Thu, 28 Feb 2019, Damian McGuckin wrote:

> > Hm, no, for x86 with GCC you should not see that: the compiler knows how to
> > expand isnan efficiently.  Are you perhaps on OS X and the 'gcc' command
> > actually invokes Clang/LLVM?
> 
> No.
> 
> > If not, can you show output of 'gcc -v', command-line flags you used, and
> > the assembly you're seeing?
> 
> 	gcc -O3 -S -msse4.2 -mfma mynan.c

Ah, in this case you're falling victim of a problem in your Glibc version:
while GCC is sufficiently new to know how to expand isnan efficiently,
Glibc math.h defines isnan as a macro that redirects to __isnan that GCC
does not recognize. Newer Glibc versions use __builtin_isnan where suitable,
which leads to optimal assembly.

(musl does not use this builtin, expanding the macro to a bit test instead)

Alexander

Re: FE Exception triggered by comparison

[Rich Felker]

On Wed, Feb 27, 2019 at 07:32:01PM +0300, Alexander Monakov wrote:
> On Thu, 28 Feb 2019, Damian McGuckin wrote:
> 
> > > Hm, no, for x86 with GCC you should not see that: the compiler knows how to
> > > expand isnan efficiently.  Are you perhaps on OS X and the 'gcc' command
> > > actually invokes Clang/LLVM?
> > 
> > No.
> > 
> > > If not, can you show output of 'gcc -v', command-line flags you used, and
> > > the assembly you're seeing?
> > 
> > 	gcc -O3 -S -msse4.2 -mfma mynan.c
> 
> Ah, in this case you're falling victim of a problem in your Glibc version:
> while GCC is sufficiently new to know how to expand isnan efficiently,
> Glibc math.h defines isnan as a macro that redirects to __isnan that GCC
> does not recognize. Newer Glibc versions use __builtin_isnan where suitable,
> which leads to optimal assembly.
> 
> (musl does not use this builtin, expanding the macro to a bit test instead)

Are there reasons we should perhaps use the __builtin versions of
these when __GNUC__ indicates they're available? I like our bit test
versions we have now, and I think they're sufficiently efficient, but
I'm open to changes if there's a good reason.

Rich

Re: FE Exception triggered by comparison

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2019-02-27 11:42:25 -0500]:
> On Wed, Feb 27, 2019 at 07:32:01PM +0300, Alexander Monakov wrote:
> > On Thu, 28 Feb 2019, Damian McGuckin wrote:
> > 
> > > > Hm, no, for x86 with GCC you should not see that: the compiler knows how to
> > > > expand isnan efficiently.  Are you perhaps on OS X and the 'gcc' command
> > > > actually invokes Clang/LLVM?
> > > 
> > > No.
> > > 
> > > > If not, can you show output of 'gcc -v', command-line flags you used, and
> > > > the assembly you're seeing?
> > > 
> > > 	gcc -O3 -S -msse4.2 -mfma mynan.c
> > 
> > Ah, in this case you're falling victim of a problem in your Glibc version:
> > while GCC is sufficiently new to know how to expand isnan efficiently,
> > Glibc math.h defines isnan as a macro that redirects to __isnan that GCC
> > does not recognize. Newer Glibc versions use __builtin_isnan where suitable,
> > which leads to optimal assembly.
> > 
> > (musl does not use this builtin, expanding the macro to a bit test instead)
> 
> Are there reasons we should perhaps use the __builtin versions of
> these when __GNUC__ indicates they're available? I like our bit test
> versions we have now, and I think they're sufficiently efficient, but
> I'm open to changes if there's a good reason.

yeah, a target may have slow fpreg->greg moves to do the bit checks,
but fast single instruction check on the fpreg and then the builtin
would be preferred.

Re: FE Exception triggered by comparison

[Alexander Monakov]

On Wed, 27 Feb 2019, Rich Felker wrote:

> Are there reasons we should perhaps use the __builtin versions of
> these when __GNUC__ indicates they're available? I like our bit test
> versions we have now, and I think they're sufficiently efficient, but
> I'm open to changes if there's a good reason.

Well, it really depends on what one considers 'sufficiently efficient'.
Instead of comparing a register with itself and testing flags (2 instructions)
you get (for 'int f(double x){return isnan(x);}'):

f:
        movabsq $9223372036854775807, %rdx
        movq    %xmm0, %rax
        andq    %rdx, %rax
        movabsq $9218868437227405312, %rdx
        cmpq    %rdx, %rax
        seta    %al
        movzbl  %al, %eax
        ret

(note that movq %xmm0, %rax is going to be more costly than a normal
move as it crosses from fp to integer domain in the cpu)

I think musl bit test can be implemented more efficiently via right-shifting
the representation in %rax first, avoiding 64-bit immediates, but even then
I'd say the "native" version is preferable.

Alexander

Re: FE Exception triggered by comparison

[Rich Felker]

On Wed, Feb 27, 2019 at 08:14:07PM +0300, Alexander Monakov wrote:
> 
> 
> On Wed, 27 Feb 2019, Rich Felker wrote:
> 
> > Are there reasons we should perhaps use the __builtin versions of
> > these when __GNUC__ indicates they're available? I like our bit test
> > versions we have now, and I think they're sufficiently efficient, but
> > I'm open to changes if there's a good reason.
> 
> Well, it really depends on what one considers 'sufficiently efficient'.
> Instead of comparing a register with itself and testing flags (2 instructions)
> you get (for 'int f(double x){return isnan(x);}'):
> 
> f:
>         movabsq $9223372036854775807, %rdx
>         movq    %xmm0, %rax
>         andq    %rdx, %rax
>         movabsq $9218868437227405312, %rdx
>         cmpq    %rdx, %rax
>         seta    %al
>         movzbl  %al, %eax
>         ret
> 
> (note that movq %xmm0, %rax is going to be more costly than a normal
> move as it crosses from fp to integer domain in the cpu)
> 
> I think musl bit test can be implemented more efficiently via right-shifting
> the representation in %rax first, avoiding 64-bit immediates,

Or left-shifting rather than masking to get rid of the sign bit?
That's all it's doing. I don't think right-shift is okay since losing
any low bits would break the comparison.

> but even then
> I'd say the "native" version is preferable.

I suspect this is probably true, though I also worry a bit whether
there are archs where it does something inefficient or broken.

Ideally the compiler would be able to recognize portable (within IEEE)
patterns for floating point representation examination and optimize
them if there's a more efficient way to be able to do it for a
particular machine.

Rich

Re: FE Exception triggered by comparison

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2019-02-27 12:26:41 -0500]:
> On Wed, Feb 27, 2019 at 08:14:07PM +0300, Alexander Monakov wrote:
> > On Wed, 27 Feb 2019, Rich Felker wrote:
> > 
> > > Are there reasons we should perhaps use the __builtin versions of
> > > these when __GNUC__ indicates they're available? I like our bit test
> > > versions we have now, and I think they're sufficiently efficient, but
> > > I'm open to changes if there's a good reason.
> > 
> > Well, it really depends on what one considers 'sufficiently efficient'.
> > Instead of comparing a register with itself and testing flags (2 instructions)
> > you get (for 'int f(double x){return isnan(x);}'):
> > 
> > f:
> >         movabsq $9223372036854775807, %rdx
> >         movq    %xmm0, %rax
> >         andq    %rdx, %rax
> >         movabsq $9218868437227405312, %rdx
> >         cmpq    %rdx, %rax
> >         seta    %al
> >         movzbl  %al, %eax
> >         ret
> > 
> > (note that movq %xmm0, %rax is going to be more costly than a normal
> > move as it crosses from fp to integer domain in the cpu)
> > 
> > I think musl bit test can be implemented more efficiently via right-shifting
> > the representation in %rax first, avoiding 64-bit immediates,
> 
> Or left-shifting rather than masking to get rid of the sign bit?
> That's all it's doing. I don't think right-shift is okay since losing
> any low bits would break the comparison.
> 
> > but even then
> > I'd say the "native" version is preferable.
> 
> I suspect this is probably true, though I also worry a bit whether
> there are archs where it does something inefficient or broken.

e.g. isnan is broken with -fsignaling-nan since it should
not signal but the ucomisd gcc generates does as discussed.

(although it's unlikely to matter much: we dont support
snan in all apis)

but gcc used to generate horrible code for fpclassify things,
nowadays it should be mostly fixed, i don't remember if
there were actual correctness bugs or just inefficient code.

> 
> Ideally the compiler would be able to recognize portable (within IEEE)
> patterns for floating point representation examination and optimize
> them if there's a more efficient way to be able to do it for a
> particular machine.
> 
> Rich

Re: FE Exception triggered by comparison

[Alexander Monakov]

On Wed, 27 Feb 2019, Rich Felker wrote:

> Or left-shifting rather than masking to get rid of the sign bit?
> That's all it's doing. I don't think right-shift is okay since losing
> any low bits would break the comparison.

Right, thanks. Make it a rotate then: with a rotate you can place the
exponent in the least significant bits, then force sign bit to 1 and
compare against a small immediate.

(note that on 32-bit this bit test makes a mess for doubles anyhow)

> > but even then
> > I'd say the "native" version is preferable.
> 
> I suspect this is probably true, though I also worry a bit whether
> there are archs where it does something inefficient or broken.
> 
> Ideally the compiler would be able to recognize portable (within IEEE)
> patterns for floating point representation examination and optimize
> them if there's a more efficient way to be able to do it for a
> particular machine.

There's a difference for sNaN operands: the bit-test version obviously
is not going to raise "invalid", while comparing the fpu register with
itself will.  So I'm afraid the compiler wouldn't do that for x86 (but
could for targets where an suitable instruction is available).

Alexander

Re: FE Exception triggered by comparison

[Szabolcs Nagy]

* Alexander Monakov <amonakov@ispras.ru> [2019-02-27 22:48:02 +0300]:
> On Wed, 27 Feb 2019, Rich Felker wrote:
> > Ideally the compiler would be able to recognize portable (within IEEE)
> > patterns for floating point representation examination and optimize
> > them if there's a more efficient way to be able to do it for a
> > particular machine.
> 
> There's a difference for sNaN operands: the bit-test version obviously
> is not going to raise "invalid", while comparing the fpu register with
> itself will.  So I'm afraid the compiler wouldn't do that for x86 (but
> could for targets where an suitable instruction is available).

using -fsignaling-nan is extremely rare, by default the transformation
is valid (but maybe tricky anyway).

Re: FE Exception triggered by comparison

[Rich Felker]

On Wed, Feb 27, 2019 at 09:16:09PM +0100, Szabolcs Nagy wrote:
> * Alexander Monakov <amonakov@ispras.ru> [2019-02-27 22:48:02 +0300]:
> > On Wed, 27 Feb 2019, Rich Felker wrote:
> > > Ideally the compiler would be able to recognize portable (within IEEE)
> > > patterns for floating point representation examination and optimize
> > > them if there's a more efficient way to be able to do it for a
> > > particular machine.
> > 
> > There's a difference for sNaN operands: the bit-test version obviously
> > is not going to raise "invalid", while comparing the fpu register with
> > itself will.  So I'm afraid the compiler wouldn't do that for x86 (but
> > could for targets where an suitable instruction is available).
> 
> using -fsignaling-nan is extremely rare, by default the transformation
> is valid (but maybe tricky anyway).

I'm not sure if I'd call transforming non-floating-point
bit-manipulation code into a floating point instruction that alters
exception flags "valid" regardless of the -fsignaling-nan state. It's
one thing to say "this program isn't using and doesn't care about
signaling nans [as floating point values]"; it's completely different
to say "you can optimize integer operations as floating point without
regard for how that affects fenv".

Rich

Re: FE Exception triggered by comparison

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2019-02-27 15:35:03 -0500]:
> On Wed, Feb 27, 2019 at 09:16:09PM +0100, Szabolcs Nagy wrote:
> > * Alexander Monakov <amonakov@ispras.ru> [2019-02-27 22:48:02 +0300]:
> > > On Wed, 27 Feb 2019, Rich Felker wrote:
> > > > Ideally the compiler would be able to recognize portable (within IEEE)
> > > > patterns for floating point representation examination and optimize
> > > > them if there's a more efficient way to be able to do it for a
> > > > particular machine.
> > > 
> > > There's a difference for sNaN operands: the bit-test version obviously
> > > is not going to raise "invalid", while comparing the fpu register with
> > > itself will.  So I'm afraid the compiler wouldn't do that for x86 (but
> > > could for targets where an suitable instruction is available).
> > 
> > using -fsignaling-nan is extremely rare, by default the transformation
> > is valid (but maybe tricky anyway).
> 
> I'm not sure if I'd call transforming non-floating-point
> bit-manipulation code into a floating point instruction that alters
> exception flags "valid" regardless of the -fsignaling-nan state. It's
> one thing to say "this program isn't using and doesn't care about
> signaling nans [as floating point values]"; it's completely different
> to say "you can optimize integer operations as floating point without
> regard for how that affects fenv".

ok i assumed gcc would also detect that the source of those bits
are from an fp value, but that may be too much to ask (and may
still have the same safety issue if the fp value is not from
normal fp computations).