On Fri, 7 Feb 2025, LIU Hao wrote:
在 2025-02-06 22:23, Jacek Caban 写道:
FWIW, that's the approach we take in Wine for entire CRT modules (not just
static parts like mingw- w64-crt's counterpart), and it works well. Most
optimizations lost this way can be addressed by writing efficient C code
from the start, avoiding the need to second-guess how the compiler will
handle it. I'd be in favor of applying the same approach to mingw-w64.
I agree.
Maybe it's just me, but committing compiler-generated assembly to the tree
feels like a sign that something isn't quite right...
As for this specific case, handwritten assembly is hardly any better than
this generated stuff.
Yes it's not that we could do better - it's just unnecessary code to have
standalone assembly for something where the compiler could do the same.
There are of course a number of cases where we _do_ need assembly, but
ideally we should limit that to the cases where we really do need it. (For
arm64ec support, there will probably be a need to touch a lot of the
assembly files we have.)
If there's no opposition to building the whole mingw-w64-crt with
-fno-builtin, I think that would be a good direction; this is quite
special code and we want to make sure that we call exactly the function we
intend to, not letting the compiler rewrite things back into what we're
trying to implement.
I think it's still probably best to apply this patchset as is, and then
apply -fno-builtin, and we can convert these files, the corresponding
existing arm ones, plus other similar functions back to C code.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
