MlasThreadedBufAlloc() and its ThreadedBufHolder guarded the
_aligned_malloc / _aligned_free path on _MSC_VER. Non-MSVC Windows
toolchains (MinGW, clang) therefore fell through to posix_memalign(),
which the Windows CRT does not provide, so the build failed with
"'posix_memalign' was not declared in this scope".
Guard the aligned-allocation path on _WIN32 instead, in both the holder
declaration (mlasi.h) and definition (platform.cpp) so the unique_ptr
deleter type stays consistent across translation units, and include
<malloc.h> on Windows since MinGW only declares the _aligned_* functions
there. The non-Windows posix_memalign / aligned_alloc fallback is
unchanged.
Fixes#29350
Fix MLAS 32-bit x86 build by integrating missing upstream assembly files #29226
### Pull Request Readiness Checklist
This resolves the 32-bit x86 build failure for MLAS. Related to: https://github.com/opencv/opencv/pull/29218
* Added the required `x86` assembly files and headers from upstream.
* Added `__x86_64__` guards around the AMX `syscall` and the FMA3/AVX512F kernel assignments to prevent 32-bit compilation crashes.
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Added MLAS third party module and integrated into GeMM path #28934
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake