Added zend_simd.h

[SakiTakamachi]

For SIMD using 128-bit vectors, add a header file to use common code between SSE2 and ARM Neon.

I don't intend to replace everything with these.
The goal is to avoid having to copy a lot of "almost identical code" for non-SIMD code on ARM.

There are other places could use it, but it would involve too many changes, so I'll address that in a follow-up PR.

[dstogov]

I don't have a strong opinion about this.

On one hand this enables NEON code on AArch64 almost for free.
On the other hand this requires usage of our own undocumented abstraction layer.
Most probably this layer is more limited than SSE or NEON by their selves.

Personally, I would prefer something like NEON2SSE (e.g. https://github.com/intel/ARM_NEON_2_x86_SSE)

[SakiTakamachi]

@dstogov

Thank you for checking!

There isn’t much SIMD code in php-src yet, so for now I chose not to use any external libraries.
However, as you mentioned, using a library would provide greater flexibility, and I have absolutely no problem switching to a library if needed.

Since the SIMD code currently in php-src is based on SSE, NEON2SSE might not fit our purpose, as the direction is reversed.

We probably need something like sse2neon:
https://github.com/DLTcollab/sse2neon

Or alternatively:
https://github.com/simd-everywhere/simde

What do you think about these libraries?

[dstogov]

Since the SIMD code currently in php-src is based on SSE, NEON2SSE might not fit our purpose, as the direction is reversed.

OK I didn't look too deep. Anyway, all these libraries are more complex then we really need. It may be simpler to create our own neon<-->sse wrapper that implements SSE intrinsics through NEON instructions. Similar to the API you proposed, but without introducing new "naming". This way the subset of supported SSE code should start to work on NEON out of the box.

Finally, it may be better to duplicate code with native NEON optimization instead of trying reusing SSE optimized code.

These are just my thoughts. I'm not sure what solution is the best.

[SakiTakamachi]

@dstogov

It may be simpler to create our own neon<-->sse wrapper that implements SSE intrinsics through NEON instructions. Similar to the API you proposed, but without introducing new "naming". This way the subset of supported SSE code should start to work on NEON out of the box.

Sounds simple and good.
I’ll try to revise it based on that idea!

Finally, it may be better to duplicate code with native NEON optimization instead of trying reusing SSE optimized code.

If the differences in code due to optimization are likely to be significant, I think it’s better to write them separately.
If the differences are small, a wrapper might be sufficient.

[SakiTakamachi]

Since bcmath had its own simd.h, I reverted those changes and modified it to use zend_simd.h instead.

As for other parts, I updated them where the current definitions in zend_simd.h are sufficient for now.