For Qt 6.4, I'd like to propose we change the way we detect and enable SIMD support. TL;DR:
* Assume all compilers support 5-year-old stuff * Up the minimum CPU for Linux, Window and macOS/x86 * Fix macOS Universal builds to use the minimum * Add an option to cmake to choose a minimum matching one of the Linux x86-64 ABI revisions * Make it easy to build QtCore, QtGui ad Qt3D multi-arch on Linux Long version: 1) assume all compilers support what we need Our current tests for compiler support go all the way back to SSE2, which is mandatory on x96-64. While testing some changes, I've confirmed that all compilers in the CI support x86 CPU features matching the Intel Cannon Lake architecture, which is more than we need, except for the QCC compiler missing one intrinsic that we can workaround. I've also found that macOS universal builds, WASM, Android and maybe some more are improperly detecting support. Specifically for universal builds, what we detect depends on the order in which you specify the architectures. This is buggy at a minimum, surprising at best. I propose we remove the tests for the intrinsics of each individual CPU feature. Instead, let's just assume they all have everything up to 2016. This will shorten cmake time a little and fix the macOS universal builds. It'll also change how 32-bit non-SSE2 builds are selected (see below). The change https://codereview.qt-project.org/c/qt/qtbase/+/386738 is going in this direction but retains a test (all or nothing). I'm proposing now we remove the test completely and just assume. Question: - the QT_COMPILER_SUPPORTS_xxx macros are in qconfig.h (public config). Do we keep compatibility? We can easily just move them to qprocessordetection. 2) add options to select the target architecture revision Linux established 3 new revisions of the architecture: * x86-64 v1 (baseline): SSE2 support * x86-64 v2: baseline + SSE3, SSSE3, SSE 4 * x86-64 v3: v2 + AVX + AVX2 + FMA + BMI + F16C * x86-64 v4: v3 + AVX512F + BW + DQ + VL + ER For i386, we can consider a "v0" of the non-SSE2 original baseline from the 1980s. I propose adding a CMake option to make it easy to opt in to one of those. Yes, you can just set CMAKE_C(XX)FLAGS_{RELEASE,DEBUG,RELWITHDEBINFO}, so this part would be convenience. For the default, see #4. 3) add a way to have multi-arch glibc-based Linux builds The revisions also match subdirectory searches by the Linux dynamic linker. The subdirectories"x86-64-v2", "x86-64-v3" and "x86-64-v4" are new in glibc 2.33, but glibc has supported "haswell" (for v3) and "avx512_1" (for v4) for a number of years prior to that. The proposal is to allow the user to specify more than one architecture in the list above. We can query the dynamic linker to find out if it supports the new names and, if not, use the old ones. For example, if I specified QT_X86_SUBARCH="v2;v3;v4", it would compile QtCore three times. The build products would be: lib/libQt6Core.so.6.4.0 lib/haswell/libQt6Core.so.6.4.0 OR lib/glibc-hwcaps/x86-64-v3/libQt6Core.so.6.4.0 lib/haswell/avx512_1/libQt6Core.so.6.4.0 OR lib/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.4.0 with their matching symlinks. This would apply to only a few select libraries. I'm thinking QtCore, QtGui, QtQml and some of the Qt3D libraries. I don't currently see a need to do this for any plugins and there is no standardised way to name them anyway. This would replace the current "-mno-sse2" option that is required to turn i386 32-bit builds from SSE2 support back to the original baseline. For a 32- bit build, one would use QT_x86_SUBARCH="v0;v1" and get both baseline and the SSE2-optimised version. 4) up the defaults from where they are today Today, your default Qt build will always target the x86-64 baseline[*], including for i386, despite as I said no CPU failing to meet the next level for 9 years. I'd like to request we up that minimum. By default, I'd like us to produce x86-64 v2 code, which is SSE4. There are a number of optimisations in QtCore and QtGui that get automatically enabled. In particular, qstring.cpp does not do runtime detection, so you've been leaving performance on the table on your computers, unless you build Qt from source yourself and set -march= to match your CPU. I'm told that Red Hat 9 will increase their minimum to v2, which is why the architecture selection features now exist. This would apply to source and binary builds from qt.io. Android and macOS would be unaffected because they already default to this level. Question: - iOS simulator builds are x86, but currently only SSE2. Does anyone know if raising to SSE4, which *ALL* 64-bit Mac machines support, would be a problem? 5) for glibc-based Linux, add v3 sub-arch by default I'd like to raise the default on Linux from baseline to v2 *and* add a v3 sub- arch build, as described by point #3 above. Device-specific Qt builds (Yocto Project, Boot2Qt) would need to turn this off and select a single architecture, if they don't want the extra files. 6) for macOS, raise the minimum to v3 (x86_64h) macOS has supported an extra architecture called "x86_64h" for some time (the "h" stands for "haswell"). Apple ceased offering macOS updates to processors without AVX2 back with the Mojave release (10.14) in 2018. Since that's the minimum version we require for Qt, it means all Intel-based Macs Qt can run on also support this sub-arch. I'd like to do this for all libraries and by default on binaries from qt.io. However, I understand the ARM translation application cannot deal with the AVX instructions, so it would fail to run our default binaries for the applications that couldn't rebuild as ARM. Is it acceptable to require those application developers to rebuild Qt from source? If not, I'd like to ask we build the same libraries as enabled for Linux multi-arch with the additional "x86_64h" architecture (that is, triple universal build: "x86_64;x86_64h;aarch64"). I'm assuming here that we can use CMake's built-in support for macOS universal builds. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
