On 1.04.2025 22:43, Martin Storsjö wrote:
On Tue, 1 Apr 2025, Jacek Caban wrote:
In preparation for using naked functions.
---
For the commit message subject, perhaps you could squeeze in an
"arm64" there too, as this only covers that function? That goes for
all of these patches.
mingw-w64-crt/Makefile.am | 4 ++--
mingw-w64-crt/include/internal.h | 8 ++++++++
mingw-w64-crt/math/arm64/{trunc.S => trunc.c} | 14 +++++---------
mingw-w64-crt/math/arm64/truncf.S | 16 ----------------
mingw-w64-crt/math/arm64/truncf.c | 12 ++++++++++++
5 files changed, 27 insertions(+), 27 deletions(-)
rename mingw-w64-crt/math/arm64/{trunc.S => trunc.c} (50%)
delete mode 100644 mingw-w64-crt/math/arm64/truncf.S
create mode 100644 mingw-w64-crt/math/arm64/truncf.c
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index ba6c6b7d5..745016079 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -705,8 +705,8 @@ src_msvcrtarm64=\
math/arm64/nearbyint.S \
math/arm64/nearbyintf.S \
math/arm64/nearbyintl.S \
- math/arm64/trunc.S \
- math/arm64/truncf.S \
+ math/arm64/trunc.c \
+ math/arm64/truncf.c \
misc/__p___argc.c \
misc/__p___argv.c \
misc/__p___wargv.c \
diff --git a/mingw-w64-crt/include/internal.h
b/mingw-w64-crt/include/internal.h
index 84d52c991..b30ae0e5f 100644
--- a/mingw-w64-crt/include/internal.h
+++ b/mingw-w64-crt/include/internal.h
@@ -287,6 +287,14 @@ static inline unsigned int __mingw_statusfp(void)
return flags;
}
+#define __ASM_FUNC_CODE(name,code) \
+ asm(".text\n\t" \
+ ".p2align 2\n\t" \
+ ".globl " __MINGW64_STRINGIFY(__MINGW_USYMBOL(trunc))
"\n\t" \
+ ".def " __MINGW64_STRINGIFY(__MINGW_USYMBOL(trunc)) "; .scl
2; .type 32; .endef\n\t" \
+ __MINGW64_STRINGIFY(__MINGW_USYMBOL(trunc))
":\n\t" \
+ code "\n\t");
Just for the record; I'm not generally a fan of this kind of function
(global-scope "inline" asm); IMO it is messy and tricky for the
compiler (e.g. wrt LTO).
That said, I'm aware that Wine does use this construct quite a bit,
and it does work there, so practically it's probably fine.
(Although I'm not sure how much LTO is tested there. Building
mingw-w64-crt with LTO is probably not a recommended setup anyway, but
it should mostly work these days. At
https://github.com/mstorsjo/llvm-mingw/commits/lto-toolchain I've got
a few unmerged things for making use of it.)
Anyway, not an objection to the approach, I know there are good
reasons for it - I just wanted to state publicly that I generally
don't favour the approach, but see the reasons for it here.
I have little experience with LTO. Wine doesn’t build with LTO out of
the box, it requires some trickery with __attribute__((used)). By
providing enough information for the naked function signature, it should
be possible to declare those functions as extern used on GCC.
That said, when using naked functions, I’d expect them to be
LTO-friendly. My understanding is that they wouldn’t be any harder for
the toolchain to handle than a regular function with some inline assembly.
Thanks,
Jacek
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
