Andarwinux wrote:
> I think that's a bit overkill. The ecosystem of active mingw developers isn't
> very big (and those who are interested in arm64ec is even smaller), and all
> of them are already CCd on this PR.
1. I think the community should also be involved in this.
2. I think the Clang Area Team should evaluate the complexity this PR
introduces to Clang, as it's not just a driver option.
If more people had been involved in the decisions related to MinGW back then, I
believe this wouldn’t be an issue at all today. Shouldn’t we learn from the
lessons of history?
> It doesn't solve any existent issues
What? I'm not sure what you mean, but in fact, this solves all the existent
issues!
- The major historical mistake
- long double interoperability between {x86_64,arm64ec,aarch64}-{mingw32,msvc}
> but brings new issues by creating a parallel universe.
What parallel universe?
If you're talking about compatibility or consistency with old binaries, then
this also applies to this PR.
> As a high level idea, I think making specifically the mingw variant of
> arm64ec use 80 bit long doubles to make it more compatible with x86_64 mingw
> (which indeed is the main target it needs to be consistent and compatible
> with), is very reasonable to do.
arm64ec is indeed designed for compatibility and consistency, but not with
MinGW, rather, with MSVC.
If a program is difficult to port to aarch64 so arm64ec is needed, you can
almost assume it lacks good cross-platform design and relies on MSVC. If it can
be compiled with MinGW, it’s hard to imagine why it couldn’t be ported to
aarch64.
Of course, there are some exceptions, such as drivers and wine. But even in
those cases, the reason they use arm64ec is not for compatibility with MinGW.
If we truly care about consistency and compatibility, then rather than create
new consistency and compatibility issue to address existing one, we should
address all consistency and compatibility issues at once.
I used an LLM to generate a table to show the differences between the two
methods:
| Aspect | Switch x86-64 MinGW long double to f64 | Switch arm64ec MinGW long
double to f80 |
|---|---|---|
| Resulting formats | All six targets (x86-64 MinGW, aarch64 MinGW, arm64ec
MinGW, x86-64 MSVC, aarch64 MSVC, arm64ec MSVC) use f64. | x86-64 MinGW and
arm64ec MinGW use f80; the other four targets use f64. |
| Consistency | Fully unified long double format across all six targets. | Two
different long double formats across the six targets. |
| Implementation effort | Requires only minor mingw-w64 changes. | Requires
substantial Clang changes. |
| ABI compatibility | Breaks compatibility with existing x86-64 MinGW binaries.
| Breaks compatibility with existing arm64ec MinGW binaries and arm64ec
MinGW/MSVC compatibility. |
| Cross-target compatibility | All six targets share the same f64 long double
format and are mutually compatible. | Only x86-64 MinGW and arm64ec MinGW share
the same f80 long double format; the other four targets use f64. |
| Performance | Eliminates the x87 dependency. | Degrades arm64ec MinGW long
double performance. |
https://github.com/llvm/llvm-project/pull/237057
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
