-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix simde_math_fpclass functions so they work. #1277
base: master
Are you sure you want to change the base?
Conversation
Functions were simply mashing all results into the low bit, instead of spreading them out across the 8 bit result as intended. The 32-bit version had a wrong constant for exponent mask as well.
Thank you, @Syonyk ! Yeah, this was my code. Mea culpa. This function is used in simde/simde/x86/avx512/fpclass.h Line 27 in 1995014
Can you think of corresponding test cases that could be added to trigger your fixes? If there is an issue here, then the float16 version I wrote is probably also suspect: https://github.com/simd-everywhere/simde/blame/1995014c5990566f41cf78daa2f281b20898a6d6/simde/simde-f16.h |
Wow that is embarrassing! @Syonyk , thank you for catching this. I think we shifted the wrong value. Instead of e.g. : Here is a full example of it: https://godbolt.org/z/r61c4x3sc @mr-c why didn't we catch it in our unittests? |
That is a good question. I see that neither Augustus nor Agrippina have AVX512FP16, and the GCC version installed there (12.x) is too old to know about And the tests are not in the normal style; we don't read in a matrix of numbers but do a run-time comparison. So it is likely that the logic error was repeated. I think it would be better if we can find a machine with a new-enough compiler and CPU and re-generate the tests, but write the results out using unsigned ints so we can verify the bit patterns. simde/test/x86/avx512/fpclass.c Lines 35 to 49 in 1995014
|
For gcc14 you want to check the folder Instruction |
Hey @Syonyk ; @SGSSGene and I looked at this together today. If you have a need for a It does look like I made an error in the |
Ah, okay. They indeed do that, if that's the intended behavior. I'd assumed imm8 was just gating what was checked for performance reasons (as they're inline functions, so a compile time constant should allow some optimization), since any non-zero value in the result will evaluate as true (0x40 is just as true as 0x1, in "if" statements). Sorry, feel free to close, I'll rework my code to use them as intended... It's also worth mentioning that the negative check should probably just check the top bit. You can have entirely valid -0, -nan, -inf, etc. |
Here's the psuedocode for
|
Ah, that it is "negative finite" makes sense. I'm over in ARM spaces dealing with a different set of problems. I didn't realize this was fully mapping onto some x86 functions. |
Yeah, hence the need for me to add some doc strings to explain better |
Slightly random suggestion, for "unrelated" code. simde/simde/x86/avx512/fpclass.h Line 38 in ef361ba
If we are guaranteed that simde_math_fpclassf collapses down to a single bit, we could also write:
|
Functions were simply mashing all results into the low bit, instead of spreading them out across the 8 bit result as intended. The 32-bit version had a wrong constant for exponent mask as well.
I don't know where to put tests for things like this... here's my test code.