On Thu, 6 Feb 2025, Jacek Caban wrote:
On 6.02.2025 13:42, Martin Storsjö wrote:
So would you feel ok with doing sincos() here with __MINGW_ASM_CALL(), as
practical Clang doesn't seem to break it at the moment, even though it in
theory could do that?
It seems to me that regardless of the solution here, it would be interesting
to make Clang stop optimizing to sincos() for mingw. If we're going to expand
it back to sin() and cos() in crt, it's counter-productive to "optimize"
sin()+cos() like that in the first place. I drafted a patch for that [1], do
you think I should submit it upsteram? I know that your change affects only
UCRT, but I suspect that with msvcrt.dll the result may be similar and I
think we should treat UCRT as a primary target anyway.
With a change like that, we'd guarantee that future versions will not
"optimize" a C implementation in mingw-w64-crt.
Hmm, I'm not entirely sure here.
For current implementations on mingw-w64 on UCRT, then yes, calling
sin+cos separately is better than using sincos().
I'm not really familiar with what the modern (non x87) implementations of
sin/cos look like, but I would presume that it's possible to do sincos()
faster than sin()+cos() separately still - if someone cares about that.
E.g. on Linux platforms, GCC (and Clang) also still optimize separate
calls into sincos(), and I would presume that what e.g. glibc provides is
faster than two separate calls.
Then again, as our target probably in general is to use more of the CRT
and less of our own statically linked functions, and as the MS CRTs don't
have sincos(), it's probably not plausible that we'll ever do that.
But in any case - for UCRT, making Clang stop using sincos() wouldn't help
all that much (we can still do what this patch does); for msvcrt.dll
builds where we link in our x87 math, doing that would miss the possibly
quicker sincos() implementation there.
As for avoiding the general case of the compiler optimizing the functions
where we provide a simple forwarder; while it's arguable for sincos(),
we'd still have a couple of other similar cases, like exp2(x) -> pow(2,
x).
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
