php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #78743 Provide a configure flag to disable SIMD optimizations
Submitted: 2019-10-23 15:44 UTC Modified: 2019-10-31 10:36 UTC
From: php-bugs-2019 at ryandesign dot com Assigned:
Status: Open Package: *Compile Issues
PHP Version: 7.3.10 OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: php-bugs-2019 at ryandesign dot com
New email:
PHP Version: OS:

 

 [2019-10-23 15:44 UTC] 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.)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-10-23 15:54 UTC] 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 16:28 UTC] 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-31 10:36 UTC] nikic@php.net 
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 13:01:29 2024 UTC