Migrating from -march=nocona -msahf to -march=x86-64-v2

[dragon-archer]

Since support for Windows 8.1 have been dropped, the minimum supported system for MSYS2 have become Windows 10.

All CPUs supported by Windows 10 supports features required by x86-64-v2, so it should be safe to do this migration.

As a reference, RHEL 9 has been using x86-64-v2 since 2021, and RHEL 10 uses x86-64-v3 since 2024

[MehdiChinoune]

That baseline was based on Windows 10 not 8.1, According to microsoft requirements in https://learn.microsoft.com/en-us/windows-hardware/design/minimum/minimum-hardware-requirements-overview#download-minimum-hardware-requirements
which are:

• Compatible with the x86* or x64 instruction set.
• Supports PAE, NX and SSE2.
• Supports CMPXCHG16b, LAHF/SAHF, and PrefetchW for 64-bit OS installation
  All nocona+ CPUs satisfy these requirements

[dragon-archer]

Well, actually all CPUs in Supported AMD Processors and Supported Intel Processors supports x86-64-v2.

[MehdiChinoune]

@dragon-archer What would say to someone running Windows 10 on an old CPU that satisfy the requirments I cited above, If they report that MSYS binaries stop working on Their PCs?
Shoudl We Add requirements for MSYS2 to be "Windows 10 + x86_64-v2+ CPU" ?

[dragon-archer]

I think these situations would be very rare. From here we can find that most CPUs since 2013 and all CPUs since 2015 have supported x86-64-v2, which is at least 11 years till now, a very long time even older than Windows 10 itself.

I do think we could add "x86_64-v2+ CPU" as an extra requirement for MSYS2.

[Peter0x44]

If windows 10 doesn't have those hardware requirements, why should we impose them?

[dscho]

I think these situations would be very rare.

Now, that is a statement that fails spectacularly at raising my confidence 😆

Do we have any statistics how many users MSYS2 has? If it has, say, 10 million (which I would consider conservative, as Git for Windows alone has these kinds of download numbers occasionally, and Git for Windows users are implicitly MSYS2 users), then even a fraction of 0.1% would translate into ten thousand users being bitten by a change like this.

Note: I am not against this change per se, I am against any ill-executed/ill-considered deprecation plan that is based on thought experiments alone rather than hard numbers and proper communication/timelines.

[Andarwinux]

Windows 11 required SSE4.2 and POPCNT, and Windows 10 is also soon to reach EOL.

[Andarwinux]

I think we could first migrate clang64 to x86-64-v2 and keep nocona for ucrt64. If MSYS2 decided to drop support for Windows 10 in the future, we could then migrate ucrt64 to x86-64-v2 as well. AFAIK users who prioritize compatibility always stick with ucrt64 or even mingw64.

[dragon-archer]

Do we have any statistics how many users MSYS2 has?

I agree we need statistics, though I think it would be difficult for MSYS2 to do this. May be we could use data from Steam Hardware Survey for reference. (I can't find more relevant survery including ISA 🙅). The latest survey (April 2026) with Windows Only filter showes that 99.86% has SSE4.2 support. I think this is high enough.

even a fraction of 0.1% would translate into ten thousand users being bitten by a change like this.

We couldn't cover all users all the time, fraction is much more meaningful than absolute couunt.

Note: I am not against this change per se, I am against any ill-executed/ill-considered deprecation plan that is based on thought experiments alone rather than hard numbers and proper communication/timelines.

I'm not asking for a sudden deprecation, but I think we should first draft a deprecation plan. For example, start from clang64 as @Andarwinux suggests.

[MehdiChinoune]

I agree we need statistics, though I think it would be difficult for MSYS2 to do this. May be we could use data from Steam Hardware Survey for reference. (I can't find more relevant survery including ISA 🙅). The latest survey (April 2026) with Windows Only filter showes that 99.86% has SSE4.2 support. I think this is high enough.

We could not use Gamers statistics as a reference, Gamers use Powerful new HW in General.

[Peter0x44]

@dragon-archer I really think you're jumping the gun here and are a little too eager to make this change. You haven't provided evidence of how much perf difference it makes. Your claims are packed with assumptions.
I personally think this is a bad idea and would only do this when msys2 drops support for windows 10, which is separate from Microsoft's schedule and not correlated.

[Andarwinux]

So I suggest we start by testing clang64 to be able to gather feedback including performance and whether it causes real users to complain that it doesn’t work.

[MehdiChinoune]

benchmarks suggest that x86_64-v2 has not a significant increase in performance, while x86_64-v3 has, because of AVX+AVX2+FMT which help many apps that rely on computing.

[Andarwinux]

Well, personally I prefer x86-64-v3 as well, but since even x86-64-v2 has faced so much opposition, I don’t hold out much hope for it.

[dragon-archer]

Indeed, x86-64-v2 doesn't gain a significant performance increase, while x86-64-v3 has (for example, doubled performance from xxhsum -b in XXH3_64b and XXH128), mostly comes from doubled SIMD length.

However, jump to x86-64-v3 is obviously more difficult, so I propose to switch to x86-64-v2 (may be gradully) first.

[Andarwinux]

runtime detection might make the most sense here.

How? Windows/COFF even doesn't support hwcap.

[mati865]

How? Windows/COFF even doesn't support hwcap.

Via downstream implementations like https://doc.rust-lang.org/core/arch/index.html#dynamic-cpu-feature-detection

[lhmouse]

AFAICT there are two main ways to use SSE/AVX:

1. To do runtime dispatching. This means to write specific code where a feature is available, and to provide a generic fallback path without it.
2. To not do runtime dispatching. This assumes that the compiler will compile it into optimal machine code if the current target allows it, and will compile to generic code otherwise.

For 1 there's likely no benefit, unless -march eliminates runtime dispatching; we focus on 2. This is a list of new instructions in x86-64-v2 which I think generic code may be compiled into so there will be benefits:

1. FISTTP (SSE3): This does conversion from long double to an integer type with truncation, without tampering with the x87 control word. On x86-32 this is also used for conversion from float/double to int64_t.
2. ROUND[PS][SD] (SSE4.1): These correspond to standard rounding functions floor[f], ceil[f], trunc[f], and nearbyint[f].
3. P{MIN,MAX}{SB,UW,SD,UD} (SSE4.2): These can be involved in auto-vectorization of computation of min/max values of integers.
4. POPCNT (POPCNT): This can be used, for example, to calculate the number of active CPU cores from SYSTEM_INFO::dwActiveProcessorMask.

[dragon-archer]

I've got a new idea. Maybe we do not have to provide a complete new environment UCRT64v3. Instead, we can make it an opt-in upper layer of UCRT64.

To be specific, every UCRT64v3 package (mingw-w64-ucrtv3-x86_64-xxx as an example) will provide and conflict with its UCRT64 varient (mingw-w64-ucrt-x86_64-xxx). The installation prefix will still be /ucrt64, and its depends (or makedepends and checkdepends) will still be written in UCRT64 style (i.e. mingw-w64-ucrt-x86_64-yyy).

The reason this can be done is that mixing UCRT64v3 packages and UCRT64 packages are DEFINITELY SAFE as long as your CPU supports x86-64-v3, and it's true that not all packages worth rebuilding for UCRT64v3 (i.e. tzdata 😆). By doing so, we can only rebuild a subset of packages for UCRT64v3, while users of UCRT64v3 can still have all UCRT64 packages available.

There might need some change to PKGBUILDs, pacman.conf and makepkg_mingw.d/.
First, a new prefix (e.g. MINGW_PACKAGE_BASE_PREFIX) need to be added. For existing environments it should be same to MINGW_PACKAGE_PREFIX, while for UCRT64v3 it should be mingw-w64-ucrt-x86_64.
Second, all packages that will be added for UCRT64v3 should use MINGW_PACKAGE_BASE_PREFIX instead of MINGW_PACKAGE_PREFIX for its depends, the provides and conflicts can be added inside if.
Finally, we can add a commented [ucrt64v3] section in pacman.conf, and anyone who wants to enable this can uncomment it manually (like staging).

I'm currently more focused on having a x86-64-v3 varient than upgrading the base to x86-64-v2, not sure whether I should open a new thread, or keep everything here?

[Master-Hash]

The reason this can be done is that mixing UCRT64v3 packages and UCRT64 packages are DEFINITELY SAFE as long as your CPU supports x86-64-v3

Safe, but mixing SSE instructions with AVX will result in a transition penalty.

https://www.intel.com/content/dam/develop/external/us/en/documents/11mc12-avoiding-2bavx-sse-2btransition-2bpenalties-2brh-2bfinal-809104.pdf

[dragon-archer]

Safe, but mixing SSE instructions with AVX will result in a transition penalty.

If a program/library is heavly using SSE instructions, most likely it'll gain to be rebuilt with AVX2, so I don't think this will be a real problem. And even if it really occurs, a simple rebuild of relevant package can solve it.

[lhmouse]

@dragon-archer

Safe, but mixing SSE instructions with AVX will result in a transition penalty.

If a program/library is heavly using SSE instructions, most likely it'll gain to be rebuilt with AVX2, so I don't think this will be a real problem. And even if it really occurs, a simple rebuild of relevant package can solve it.

System libraries do use SSE2, but they can't be rebuilt. You probably need -mvzeroupper.

The performance penalty of SSE-AVX transitions varies between micro-architectures; see https://johnk.dev/articles/vex-transition-penalties.html.

[dragon-archer]

System libraries do use SSE2, but they can't be rebuilt. You probably need -mvzeroupper.

This is enabled by default for -O2 and above

gcc -Q --help=target -march=x86-64-v3 -O2 | grep zeroupper
  -mvzeroupper                          [enabled]

[mati865]

Is it even relevant? You don't call one-off AVX instructions by yourself in the mentioned case.
What you typically do is you have some chunk of scalar data that you want to be transformed by a library. The library will convert that data to vectors, do transformations and return scalar form back. So, the price has to be paid anyway.

Even if you use SSE/AVX types in the API and mix one library built for SSE (libfoo) with other built for AVX2 CPU (libbar), the API must remain stable.
So, if libfoo calls libbar passing it SSE types, libbar won't suddenly use AVX just because it was built for more featureful CPU.

While you shouldn't mix different, incompatible instruction sets within hot code section (for example inside a loop), I don't see how it would be applicable to the libraries.

[Andarwinux]

The benefit of whole-system x86-64-v3 is to eliminate unnecessary vzeroupper with -mno-vzeroupper, although this is not actually applicable on Windows since system libraries only use SSE anyway. (This is primarily useful for clang, because gcc can use VEX tricks to avoid unnecessary vzeroupper as much as possible, whereas clang cannot)

-mno-vzeroupper also enable the use of vectorcall calling conventions everywhere, but currently this is meaningless as no compiler provides function call (VFABI) automatic vectorization.

[MichalPetryka]

I've seen a few not fully correct statements in this thread so I'd like to clarify a few things:

• Windows is only actually requiring x86-64-v2 since Windows 11 24H2, but the amount of users without it is miniscule so breaking them could be okay. For reference here, Microsoft .NET will start requiring x86-64-v2 in .NET 11, to be released this year.
• x86-64-v3 is not feasible to require, Intel shipped CPUs without AVX as late as 2018 AFAIR, including ones supported by Windows 11. Additionally, there's still a relatively big amount of people on Intel 2nd gen which only has AVX and not AVX2. AVX support can also be disabled in system or BIOS settings and some users do have it disabled. Another concern is emulation tools, Wine only started supporting AVX like 2 years ago, Windows Prism added it in 24H2 but it's opt in for 32bit and I've heard some people say that some instructions are broken and on MacOS Rosetta started supporting AVX but reports it as disabled AFAIR. You can also see that a few games like Cyberpunk tried to move to x86-64-v3 but had to revert due to people complaining.
• x86-64-v4 (and thus AVX512) is not dead ever since Intel changed the AVX10.1 spec to guarantee it being a strict superset of AVX512 and guarantee AVX512 code running with it. As such, it can be assumed that every future desktop CPU from both Intel and AMD will support x86-64-v4.

Probably the most useful part to require from x86-64-v2 are the variable indices shuffle instructions from SSSE3, as in x86-64-v1 shuffles require constant indices.

Additionally, both the Windows system libraries and the CRT do use AVX, AVX2 and even AVX512 in their code, but always under runtime availability checks.

For the AVX-SSE transition penalty topic, AFAIR it's always basically minimal if the compiler guarantees emitting vzeroupper after any AVX usages, which is basically free on any modern CPUs and there's basically no reason to avoid it.

There's also need to consider that Windows Server versions based on Windows 10 that do not require x86-64-v2 are going to be supported for a few years still and likely to use MSYS2 for CI purposes.

As such, I'd say that only x86-64-v2 can be okay to hard require and any code that wants to use stuff newer than it should use runtime checks for availability.

[Andarwinux]

• x86-64-v3 is not feasible to require, Intel shipped CPUs without AVX as late as 2018 AFAIR, including ones supported by Windows 11.

If people were able to buy AVX2-capable CPUs with same price but not, then the problem is their own stupidity.

• AVX support can also be disabled in system or BIOS settings and some users do have it disabled.

That's their problem.

• Wine only started supporting AVX like 2 years ago,

Why should MSYS2 support older wine? If users refuse to upgrade, that’s their problem.

• Windows Prism added it in 24H2 but it's opt in for 32bit and I've heard some people say that some instructions are broken and on MacOS Rosetta started supporting AVX but reports it as disabled AFAIR.

MSYS2 provides clangarm64. if users choose to use x86-64 envs, that's their problem.

There's also need to consider that Windows Server versions based on Windows 10 that do not require x86-64-v2 are going to be supported for a few years still and likely to use MSYS2 for CI purposes.

There are no GitHub Action runners which don't support AVX2.

emitting vzeroupper after any AVX usages, which is basically free on any modern CPUs and there's basically no reason to avoid it.

https://uops.info/html-instr/VZEROUPPER.html

AMD Zen 2
Measurements
Throughput
Measured (loop): 5.00
Measured (unrolled): 5.00
Number of μops
Executed: 12
Documentation
Throughput: 0.25
Number of μops: 1
AMD Zen+
Measurements
Throughput
Measured (loop): 6.00
Measured (unrolled): 6.00
Number of μops
Executed: 17
Documentation
Throughput: 6.00
Number of μops: ucode

[MehdiChinoune]

A recent benchmark from Phoronix of Ubuntu amd64 (x86_64) vs amd64v3 (x86_64-v3) https://www.phoronix.com/review/ubuntu-2610-amd64v3

[lhmouse]

A recent benchmark from Phoronix of Ubuntu amd64 (x86_64) vs amd64v3 (x86_64-v3) https://www.phoronix.com/review/ubuntu-2610-amd64v3

Can I summarize it as 'the performance differences are usually negligible'?

[dscho]

A recent benchmark from Phoronix of Ubuntu amd64 (x86_64) vs amd64v3 (x86_64-v3) https://www.phoronix.com/review/ubuntu-2610-amd64v3

Can I summarize it as 'the performance differences are usually negligible'?

I would go a step further. The Java/R/POV-Ray penalties (where the changes hurt instead of benefit) suggest that the benchmarks I asked for (by the people who are so in love with making this breaking change) should probably be a mandatory prerequisite to even consider any further steps. It the net result is as mixed as in that article, it might be a really bad idea to even consider spending any more effort on this.