On Thu, 6 Feb 2025, LIU Hao wrote:
在 2025-02-06 21:23, Martin Storsjö 写道:
I was bitten by Clang's `__asm__` before so I don't really recommend it
unless we know for sure that optimization is safe.
Oh - specifically around __asm__ for redirecting functions to a specific
symbol, or for inline assembly? (We do rely on __asm__ for function
redirects a fair bit in the headers, for stdio function redirects already.)
It's like this: https://gcc.godbolt.org/z/EGWovGo3P
Clang attempts to inline the target function which leads to infinite
recursion.
Ah, right, yes I remember discussing that; thanks for the reference!
Although that feels like a distinct different case than what we have here.
See https://gcc.godbolt.org/z/Ef1Yojb5E, where I added -emit-llvm on the
Clang invocation.
On the default case, without __asm__(), we have this:
%4 = tail call double @llvm.sin.f64(double %0), !dbg !21
store double %4, ptr %1, align 8, !dbg !22
%5 = tail call double @llvm.cos.f64(double %0), !dbg !27
store double %5, ptr %2, align 8, !dbg !28
So the math functions are recognized as the standard ones, and they're
referenced to with llvm specific intrinsics like llvm.sin.f64 and
llvm.cos.f64. For the case with function renaming, we don't have that:
%4 = tail call double @sin(double noundef %0), !dbg !36
store double %4, ptr %1, align 8, !dbg !37
%5 = tail call double @cos(double noundef %0), !dbg !38
store double %5, ptr %2, align 8, !dbg !39
Here we just call them as plain functions sin and cos.
As the rest of the optimization pipeline after this is language
independent, I would think the rest of the pipeline wouldn't convert
between sin and llvm.sin.f64, but I can't of course guarantee it.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
