RE: [INTERNALS-WIN] --enable-native-intrinsics issue

Hi,

> -----Original Message-----
> From: Kalle Sommer Nielsen <[email protected]>
> Sent: Friday, December 28, 2018 7:38 PM
> To: Christoph M. Becker <[email protected]>
> Cc: internals-win <[email protected]>
> Subject: Re: [INTERNALS-WIN] --enable-native-intrinsics issue
> 
> Hi Christoph
> 
> Den fre. 28. dec. 2018 kl. 19.05 skrev Christoph M. Becker
> <[email protected]>:
> >
> > Hi!
> >
> > I've just noticed the --enable-native-intrinsics configure option, and
> > did the following on a machine which does not support AVX2:
> >
> >   configure --disable-all --enable-cli --enable-debug
> > --enable-native-intrinsics=avx2
> >
> > The build succeeds (without particular warning), but running `php -v`
> > crashes the program with:
> >
> >   Exception thrown at 0x00007FFC7ED8F70A (php7ts_debug.dll) in php.exe:
> > 0xC000001D: Illegal Instruction.
> >
> > Wouldn't it be possible to somehow detect missing support for certain
> > required SIMD extension sets, and bail out gracefully (including
> > reporting the problem) if the executable can't run on the present machine?
> 
> This is detectable, but I don't think it is through JS (even with the shell script
> objects), could you open a FR and assign it to me as I got an idea to
> something I maybe can patch up in the weekend for this?
> 
--enable-native-intrinsics doesn't require the actual host to support the chosen features. Thus, the actual features need to be present on the target machine. AVX2 is still a rare case, but most of the current x86 hardware supports AVX.

The default processor feature set is SSE2. If compiler generates some AVX2 optimized binary, it won't run on machines that don't support AVX2. An external starter tool could be used, that invokes a suitable binary depending on the feature detection. However that's not universally doable. Say for Apache where PHP is a DLL. For FCGI it might be error prone, too. And otherwise, one would have to deliver bins with different optimizations along with the default ones. So that's not a real solution. And btw, even in the SSE2 builds there's a dynamic feature detection which is used internally for some functions in the core, like addslashes(), etc. 

Still, binaries generated to use more recent CPU features might show better results. Snapshots currently produce AVX optimized binaries for 7.3 and master. I had no chance to test AVX2 yet :( In any case that's not different from other platforms when doing cross compilation. For example any distributions would usually deliver max SSE2 bins, but a user is free to use -march=native when compiling themselves. I don't see a reason to overcomplicate this, especially as there's no good way to deal with this at runtime. Implementing -march=native might make sense, but its absence is not critical. Free tools like coreinfo or cpuz are available, too.

Regards

Anatol