MSVC: Provide alternate implementations for 32-bit math functions #1446
Conversation
| @@ -6,10 +6,25 @@ | |||
| * License: Distributed under the | |||
| * $(LINK2 http://www.boost.org/LICENSE_1_0.txt, Boost Software License 1.0). | |||
| * (See accompanying file LICENSE) | |||
| * Source: $(DRUNTIMESRC rt/_stdio_msvc.d) | |||
| * Source: $(DRUNTIMESRC rt/_msvc.c) | |||
There was a problem hiding this comment.
Not sure if this leading underscore is required.
There was a problem hiding this comment.
No documentation is generated from the rt package, so it's unlikely to make a difference. It's used everywhere so better keep it.
| // Provide alternate implementations using the 64-bit double version. | ||
| #if defined _M_IX86 | ||
|
|
||
| #define IMPL(baseName) \ |
There was a problem hiding this comment.
I'd recommend to use more descriptive names for these macros, e.g. IMPL_ALT_MATHFNF.
|
I tried this change with VS2013, and the size of "hello.exe" using printf increased from 239kB to 313kB. |
Incredible. I completely forgot how primitive linkers still work in 2015 ;) - but |
kinke
force-pushed
the
msvcFloat
branch
3 times, most recently
from
2f72c69 to
98813c7
Compare
The 32-bit x86 runtime lacks most single-precision math functions (asinf(), acosf() etc.), i.e., they are only inline-declared in the C headers (and use the double-precision version). The available symbols apparently depend upon whether one's linking against the static or dynamic MS runtime (libcmt.lib vs. msvcrt.lib), and possibly upon the Visual Studio version too. So provide alternate implementations here in druntime to prevent linker errors. I came up with these 19 missing functions about a year ago by inspecting the VS 2013 headers (these should be all inline- declared ones, iirc).
My results were with the default, which seems /OPT:REF as long as /DEBUG is not passed, too. with /OPT:NOREF the change is from 346kB to 423kB.
Better, but still not optimal, as you get the full additional code when referring to one symbol. I tried compiling msvc_math.c with -Gy to put each function in its own COMDAT, but that did not change much: only the used |
|
BTW: if the single precision functions are now available for all VS versions, we should add them to core.stdc.math, too. |
| * License: Distributed under the | ||
| * $(LINK2 http://www.boost.org/LICENSE_1_0.txt, Boost Software License 1.0). | ||
| * (See accompanying file LICENSE) | ||
| * Source: $(DRUNTIMESRC rt/_msvc_math.c) |
There was a problem hiding this comment.
I think the module names would be more consistent with sections_*.d and deh_*.d if this module is called math_msvc.d.
There was a problem hiding this comment.
But there are no other math modules, contrary to sections and deh. To me, this extra module is part of msvc.c and only a separate file to help the linker somewhat.
They already are: https://github.com/D-Programming-Language/druntime/blob/master/src/core/stdc/math.d#L987
Sufficient in my eyes. ;)
I guess the double versions are each in their own module. |
Ah, I forgot about that.
Yeah, not so bad in this case. I wonder why putting functions into COMDATs doesn't work. It's the approach used by dmd aswell for all functions.
Unfortunately there is no source code for these, but the library dump suggests that the guess is correct. For example |
|
Auto-merge toggled on |
MSVC: Provide alternate implementations for 32-bit math functions
The x86 runtime lacks most *f versions (asinf(), acosf() etc.), i.e., they are only inline-declared in the C headers (and use the 64-bit double version).
The available symbols apparently depend upon whether one's linking against the static or dynamic MS runtime (libcmt.lib vs. msvcrt.lib), and possibly upon the Visual Studio version too.
So provide alternate implementations here in druntime to prevent linker errors. I came up with these 19 missing functions about a year ago by inspecting the VS 2013 headers (these should be all inline-declared ones, iirc).
Pinging @rainers.