Req #78743 [Opn]: Provide a configure flag to disable SIMD optimizations

Edit report at https://bugs.php.net/bug.php?id=78743&edit=1 ID: 78743 Updated by: nikic@php.net Reported by: php-bugs-2019 at ryandesign dot com Summary: Provide a configure flag to disable SIMD optimizations Status: Open Type: Feature/Change Request Package: *Compile Issues PHP Version: 7.3.10 Block user comment: N Private report: N New Comment: I've removed the configure-time CPU checks in https://github.com/php/php-src/commit/edccf32f7f36a8bc759b9482737e0c3efcb3a005 for PHP 7.4, but as said I don't think these are related to your issue. I don't have any immediate ideas regarding what could cause this. Previous Comments: ------------------------------------------------------------------------ [2019-10-23 16:28:32] php-bugs-2019 at ryandesign dot com Ah. Sounds like that should be ok then. I admit I have not tried to compile on a newer system and run on an older system. I can try to do that later. But if you have runtime checks for SIMD features, why are there configure checks at all? Why not just always build with support for every SIMD instruction set? Three users reported crashes to me with php73 on macOS Mojave relating to base64 and/or openssl functions. The first user referred me to commit 291589114aa9be899cf7d5d874c3b5bbdb35f336 which was a temporary fix for bug #77284 by disabling ifunc usage for FreeBSD. He suggested that doing the same thing for macOS had fixed the problem for him. A different user said that recompiling PHP with debugging enabled had fixed the problem. This made me wonder if simply recompiling on the user's own CPU was what had fixed it. The third user said that just recompiling fixed the problem. I have not been able to reproduce these crashes on my own systems. But the users have reported that their CPUs are much newer than our build server's, so I may be looking in the wrong place after all, though I'm not sure where to look next. ------------------------------------------------------------------------ [2019-10-23 15:54:21] nikic@php.net I believe that what happens here is that these do indeed check if your native CPU supports the instruction set (for whatever reason -- needs to be fixed), but it will still generate code that performs a runtime dispatch. The instruction set used without dynamic dispatch only depends on -march / -mcpu / -mattr I believe. Do you actually observe something to the contrary? ------------------------------------------------------------------------ [2019-10-23 15:44:38] php-bugs-2019 at ryandesign dot com Description: ------------ Hi, I'm the maintainer of php in MacPorts. When I configure php73 on my Mac, the output includes these lines: checking for ssse3 instructions supports... yes checking for sse4.2 instructions supports... yes checking for avx instructions supports... yes checking for avx2 instructions supports... yes checking whether __SSE4_2__ is defined... no If I understand correctly, it's checking which SIMD instruction sets are available on the current CPU, and builds a binary that uses those instructions. If that's correct, then moving that binary to a computer with a different CPU with lesser SIMD capabilities would not work, and would probably crash. This is a problem for anyone who wants to distribute binaries of php for others to use, such as MacPorts and other package management systems. I think this may be why some of our users have reported crashes with php73. Therefore I would like to disable SIMD optimizations, but I couldn't find a configure flag to do that. If there isn't one, could one be added? Or is there another way for me to indicate this at build time? It would be useful to be able to override the detection of each instruction set individually. (For example, for MacPorts, I know that every Intel Mac Apple ever shipped supported SSE3, so I would enable that and disable the rest. Or I might vary it based on deployment macOS version, since newer macOS versions often require newer computers anyway.) ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=78743&edit=1