summaryrefslogtreecommitdiffstats
path: root/src/3rdparty/libgq/debian/control
diff options
context:
space:
mode:
authorThiago Macieira <thiago.macieira@intel.com>2021-11-27 21:35:31 -0800
committerThiago Macieira <thiago.macieira@intel.com>2022-01-19 20:57:51 -0800
commitdf8456061ef0d57ea6be37746951c50f38a65101 (patch)
tree4cdc004c06266e58a88a1419db7bf247662dbcde /src/3rdparty/libgq/debian/control
parent69731bec5796beb53b5ab00388c7c21c6a01d822 (diff)
convertDoubleTo: add an x86-64 intrinsics versionHEADdev
The UB that the C and C++ standards talk about do not apply if we use intrinsics. We can rely on the processors' architectural behavior instead. There are two ways to detect a conversion that cannot be represented in the result. One would be to check if the #IE bit got set in the MXCSR, but in order to do that we'd need two issue an STMXCSR+LDMCXSR pair to clear the bit first and then another STMXCSR at the end to see if it got set. Those instructions are 4 uops long and necessarily target memory, so that's a bit slow. This commit implements the second way, which is to check if the result of the conversion is the "undefined" value. Unfortunately, that value is a valid, precise value that double can hold for all data types except unsigned 64-bit, so we need to recheck if that was the actual value stored in the original double. This implementation targets 64-bit exclusively because that avoids having to deal with the 64-bit intrinsics not even being defined in 32- bit code (converting a double to 64-bit integer in 32-bit is messy). The unsigned implementation is only implemented with AVX512F because of the unsigned conversion instructions that were introduced then. Change-Id: I89446ea06b5742efb194fffd16bb9f04b2014bab Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Diffstat (limited to 'src/3rdparty/libgq/debian/control')
0 files changed, 0 insertions, 0 deletions