[TargetLibraryInfo] Update run time support for Windows

[evandro]

Summary

It seems that the run time for Windows has changed and supports more math functions than it used to, especially on AArch64, ARM, and AMD64, since at least VS2015, if not earlier.

Fixes PR40541.

[mstorsjo]

Even if a specific version of MSVC is required to compile LLVM, code generated by LLVM can run on a wider range of msvcrt versions. (And it also works with mingw which normally uses an ancient msvcrt.)

I didn't look closely at the change itself yet.

[evandro]

In D57625#1382005, @mstorsjo wrote:

(And it also works with mingw which normally uses an ancient msvcrt.)

Indeed, this change only affects Windows proper, as both Cygwin and MinGW were already excluded from this selection of supported math functions.

[mstorsjo]

In D57625#1384112, @evandro wrote:

In D57625#1382005, @mstorsjo wrote:

(And it also works with mingw which normally uses an ancient msvcrt.)

Indeed, this change only affects Windows proper, as both Cygwin and MinGW were already excluded from this selection of supported math functions.

Oh, right - I didn't check the patch that far. Ok, so that's not a concern then.

But the other point still stands; even if compiling LLVM requires VS 2015 or newer, the generated code can work with older MSVC runtimes as well. @rnk - is there any declared minimum for this? I'm using Clang with MSVC 2013 SDK/runtimes just fine in one setup at least (although this setup currently uses Clang/LLVM 4.0, I haven't recently retested it with latest). AFAIK, the exact version of MSVC that is targeted is kept available via Triplet::getEnvironmentVersion, so unless it's intended to drop support for all the older runtimes as well, this would have to check the version of it.

Other than that, the patch is pretty hard to follow - it would be easier split up in individual changes - from my reading through it so far, I can see 3-4 different kinds of changes. E.g. moving the x86 specific single precision function block, making some math functions available, marking some other functions as unavailable (copysignf etc).

llvm/lib/Analysis/TargetLibraryInfo.cpp

168

FWIW, is64 isn't the exact right condition for this; these functions are available for ARM (32 bit) as well, it's only i386 which is the exception.

I see this if statement/block was moved, and it earlier used the condition if (T.getArch() == Triple::x86), which is correct even when taking arm/aarch64 into consideration.

225

For ucrt (VS2015 and newer), all of acosh, acoshf, acoshl are available in the crt DLL at least.

[evandro]

In D57625#1384950, @mstorsjo wrote:

But the other point still stands; even if compiling LLVM requires VS 2015 or newer, the generated code can work with older MSVC runtimes as well. @rnk - is there any declared minimum for this? I'm using Clang with MSVC 2013 SDK/runtimes just fine in one setup at least (although this setup currently uses Clang/LLVM 4.0, I haven't recently retested it with latest). AFAIK, the exact version of MSVC that is targeted is kept available via Triplet::getEnvironmentVersion, so unless it's intended to drop support for all the older runtimes as well, this would have to check the version of it.

It's not clear to me that the version of the MSVCRT is handled by the triplet. However, when I worked at AMD, we worked with MS to get them more math functions into it for x86-64, so it's probably been the case since then. However, after 15 years or so, my recollection of the details is fuzzy.

Again, I don't work on Windows, so I'd appreciate any help sorting out the legality of these changes.

llvm/lib/Analysis/TargetLibraryInfo.cpp

168

It's true that ARM is also the case. However, there are some tidbits for IA64 in MSVCRT, so I don't think that excepting i386 is safe.

225

As far as I can tell, acoshf() and acoshl() are wrappers around acosh(). Likewise for other math functions. This is confirmed by the documentation at https://is.gd/W5fT9r.

[evandro]

Include ARM.

[evandro]

Rebase.

[rnk]

Do we know when most of these were added? Did the all arrive in more or less the same version? It would be nice to make this conditional on a new enough environment version. That gives users a way to indicate that they are targetting an old CRT if they need to.

[mstorsjo]

Thanks, this looks much more readable!

It's not clear to me that the version of the MSVCRT is handled by the triplet.

Hmm, indeed. The triplet can be used to set the MSVC compatibility version though, e.g. like -target <arch>-windows-msvc19 for indicating MSVC 19 (aka 2015), which is the version that got UCRT which has got all these new functions.

I expected the reverse to be true as well, that the internal triplet gets populated with the version number, but it seems I might have misread the source. In Clang it's handled via code like LangOpts.isCompatibleWithMSVC(LangOptions::MSVC2015) and similar.

@rnk - do you know if it's possible to check the MSVC(RT) target version within LLVM somehow?

llvm/lib/Analysis/TargetLibraryInfo.cpp

168

Right, IA64 probably isn't quite the same either - I normally only consider x86/x86_64/arm/arm64... This form certainly should be safe at least.

225

Can you quote which part there says they're wrappers? I would at least expect e.g. acoshf() to be distinct from acosh(). Since long double and double are equivalent, I don't doubt that acoshl() is a wrapper around acosh() though. But in practice, even if e.g. the headers would do such redirecting, the MSVCRT (both DLL and import library) still provides all three function names, both plain, with f and l suffix.

[mstorsjo]

In D57625#1386061, @rnk wrote:

Do we know when most of these were added? Did the all arrive in more or less the same version? It would be nice to make this conditional on a new enough environment version. That gives users a way to indicate that they are targetting an old CRT if they need to.

They're certainly available since UCRT, but msvcr120.dll (MSVC 2013, aka 18.00) also seems to have at least rint, round, cbrt, exp2. (I'm checking https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/lib64/msvcr120.def.in.)

[rnk]

In D57625#1386095, @mstorsjo wrote:

They're certainly available since UCRT, but msvcr120.dll (MSVC 2013, aka 18.00) also seems to have at least rint, round, cbrt, exp2. (I'm checking https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/lib64/msvcr120.def.in.)

I don't think we need to go the extra mile to provide rint to users targeting 2013. We can reduce it to just pre-2015 and post, as is done in this patch.

llvm/lib/Analysis/TargetLibraryInfo.cpp

165

I think you can use T.getEnvironmentVersion() here to get the MSVC version. Maybe make it conditional on isWindowsMSVCEnvironment(). If there is no version or it isn't an MSVC environment, just assume full C99 support is available (i.e. the UCRT is in use).

[evandro]

In D57625#1386061, @rnk wrote:

Do we know when most of these were added? Did the all arrive in more or less the same version? It would be nice to make this conditional on a new enough environment version. That gives users a way to indicate that they are targetting an old CRT if they need to.

Goodness, I wrote this document (https://is.gd/vQYYpY) in 2004 about VS6! Just don't ask me any question about it, as it was in another life.

llvm/lib/Analysis/TargetLibraryInfo.cpp

225

This is what the document says:

When you use C++, you can call overloads of *acosh* that take and return *float* or *long* double values. In a C program, *acosh* always takes and returns *double*.

Disassembling the DLL, it's not clear that the float version just calls the double version after the proper conversions, though.

We're dealing with very poor documentation that doesn't quite match the header files that don't quite match the object file.

I'm making a judgment call for the the least common denominator: the poor documentation.

[evandro]

llvm/lib/Analysis/TargetLibraryInfo.cpp

165

What's the correlation between MSVCRT major version and VS release year?

[evandro]

llvm/lib/Analysis/TargetLibraryInfo.cpp

165

FWIW, LLVM seems to be aware only of major versions 18 and 19, according to test cases.

[rnk]

llvm/lib/Analysis/TargetLibraryInfo.cpp

165

In this case, I think it's VS 2015 == VC 19.

[evandro]

Restrict the improvements to VS2015.

[rnk]

llvm/lib/Analysis/TargetLibraryInfo.cpp

168

I think it's common for non-clang users to not have any version info in the triple. I think in these cases, we are better off setting isPartialC99 to true. For example, most of the llc tests will use version-less triples. I was mainly interested in leaving a way for users to access the old behavior by setting an old MSVC version in the triple. Sorry for the extra work, I tried to spell it out in the comments.

[evandro]

Assume VC19 as the default. However, I wonder if this should be the default earlier, in the clang driver.

[mstorsjo]

llvm/lib/Analysis/TargetLibraryInfo.cpp

182

This changes behaviour for old MSVCRT versions as well - you're hiding many orthogonal issues under the same isPartialC99 variable.

The functions here, e.g. acosf, does exist even in very old MSVCRT versions, but only on x86_64, arm and arm64, not on i386. acosf does not exist as a function in libcmt.lib or msvcrt.lib (or libucrt.lib or ucrt.lib for modern versions) for i386, not even for the latest versions of MSVC.

After this change, acosf and the others in this if statement would become unavailable for x86_64 for MSVC versions prior to 19, even though we earlier allowed and used that function for any MSVCRT version, on x86_64.

So there's two orthogonal issues at play here:

1. Some functions (f-suffixed) don't exist on some architectures, but exist on others. Regardless of MSVCRT version.

2. Some functions (acosh, rint, etc) appeared in some MSVCRT version (MSVC 19 is a good and safe threshold for this even though they might have appeared earlier) but were missing before that, regardless of architecture. And once these appeared, they appeared with all three forms (rint, rintf and rintl) at once, on all architectures (even if the l suffixed version is pointless on MSVC as long double == double).

225

This is what the document says:

When you use C++, you can call overloads of *acosh* that take and return *float* or *long* double values. In a C program, *acosh* always takes and returns *double*.

This only says that while in C mode, you have the three distinct function names acosh, acoshf and acoshl, you can also use the plain unsuffixed function name acosh in C++ mode, as C++ allows overloads. This doesn't imply that the suffixed versions like acoshf are unavailable in C++ mode - they certainly are available as well.

Disassembling the DLL, it's not clear that the float version just calls the double version after the proper conversions, though.

We're dealing with very poor documentation that doesn't quite match the header files that don't quite match the object file.

I'm making a judgment call for the the least common denominator: the poor documentation.

I don't see why one would have to disassemble the DLL to figure out what calls what or what C++ overloads exist matter at all.

At this level, within LLVM, we are past the frontend languages and don't know or care about potential redirections within math.h, and language differences between C and C++ and others are irrelevant as we are on the object file level.

The only thing matters is "can we assume that a definition of a function named acoshf will exist elsewhere at link time". And the answer to that is yes. Whether the implementation of that function simply internally calls acosh or not is irrelevant for LLVM - that doesn't disqualify its use.

[evandro]

llvm/lib/Analysis/TargetLibraryInfo.cpp

182

OK, I think that I understand what you mean. Stand by.

225

It's true that that statement is explicitly about function overloading in C++, but I suspected that there was more to it. Many math functions are defined as macros around the double version. Even then the symbol for other versions are defined in the library, but some just replicate the macro, wrapping around the double version with parameters and result conversion.

Now, I didn't do a thorough inventory of the libraries, just sampled a handful of functions. In the header file math.h it's more straightforward to figure out.

In the case of acosf, we find:

#if defined _M_X64 || defined _M_ARM || defined _M_ARM64

  _Check_return_ _ACRTIMP float __cdecl acosf(_In_ float _X);
  ...

#else

  _Check_return_ __inline float __CRTDECL acosf(_In_ float _X)
  {
      return (float)acos(_X);
  }
  ...

#endif

Even though the i386 library also provides the symbol acosf, but for a wrapper equivalent to this macro.

Bottom line is that I could not find a straightforward documentation from MS and the best that I could confidently come up with was the result of reverse engineering the files that accompany VS.

[evandro]

llvm/lib/Analysis/TargetLibraryInfo.cpp

182

Also, do you mean that that all C99 versions appeared in VC19?

[evandro]

Separated functions between VC19 and float.

[rnk]

I looked at the version checks and I'm happy with this. I haven't read all the discussion between you and @mstorsjo, but feel free to land if his concerns are addressed. Thanks for circling around and addressing this!

[mstorsjo]

llvm/lib/Analysis/TargetLibraryInfo.cpp

225

Even though the i386 library also provides the symbol acosf, but for a wrapper equivalent to this macro.

Bottom line is that I could not find a straightforward documentation from MS and the best that I could confidently come up with was the result of reverse engineering the files that accompany VS.

No, acosf is one of those that the i386 library does not provide - it's part of the block of architecture specific functions regardless of msvcrt version above.

But for the ones that are added by hasPartialC99 in your patch, let's look at e.g. cbrt - the suffixed forms cbrtf and cbrtl are also available. The documentation at https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/cbrt-cbrtf-cbrtl?view=vs-2015 say that the suffixed forms are available (the extra suffixless overloads only for C++), corecrt_math.h in the Win10 SDK contains this:

    _Check_return_ _ACRTIMP float     __cdecl cbrtf(_In_ float _X);
...
    _Check_return_ _ACRTIMP long double __cdecl cbrtl(_In_ long double _X);

And the import library, even for i386, contains this:

$ llvm-nm ucrt/x86/ucrt.lib | grep cbrt
00000000 T __imp__cbrt
00000000 T _cbrt
00000000 T __imp__cbrtf
00000000 T _cbrtf
00000000 T __imp__cbrtl
00000000 T _cbrtl

Given this, there is no doubt or inconsistency, all three references (docs, headers and import libs) agree that these functions are available in all three forms, cbrt, cbrtf and cbrtl. (Even though headers don't matter for what actually is available for linking.) Whether they internally call each other or not is irrelevant.

The same goes for all the functions in the // Win32 does not fully support C99 math functions. if (!hasPartialC99) block in the latest revision of your patch.

Now I've bothered you more than enough though; keeping it like this should be ok in the sense that it shouldn't break anything and I don't mind if you commit it in this form, even though I feel it still is inconsistent/incomplete.

264

I believe this one doesn't need the !hasPartialSP condition. logbf is available for all architectures in the version where we set hasPartialC99.

(Also, what does SP stand for in that variable name?)

Changing it into ìf (!hasPartialSP && !hasPartialC99) should be fine though, and conversely if (hasPartialSP || hasPartialC99) TLI.setAvailableWithName(LibFunc_logbf, "_logbf");` below.

[evandro]

llvm/lib/Analysis/TargetLibraryInfo.cpp

225

No, you haven't bothered me at all. I appreciate your input.

BTW, if you have a list of functions present in the i386 libraries and another in the, say, amd64 ones, as a proposal about what LLVM should know about the MSVC libraries, please do.

264

logbf was available in amd64 even before C99 was supported.

SP stands for single precision, AKA, float. I could rename it to hasPartialFloat.

[mstorsjo]

llvm/lib/Analysis/TargetLibraryInfo.cpp

225

I guess the ultimate authority for what works linking wise, is the import lib and static crt lib files themselves. If you have access to them, llvm-nm on them gives a full list.

For a more readable reference, I'd recommend the mingw def files and wine spec files. They are based on dumping the list of exported functions from the DLLs, merged into one file for all architectures, with manual annotations about functions that only are available on specific architectures.

For the current CRT version that would be:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/lib-common/ucrtbase.def.in
https://source.winehq.org/git/wine.git/blob/957a1f0216995c14c3a3fe737358578a506af707:/dlls/ucrtbase/ucrtbase.spec

E.g. for the block of if (!hasPartialSP) above, for the acosf function, the mingw def file has got this:

F_NON_I386(acosf F_X86_ANY(DATA))

(You can ignore the F_X86_ANY(DATA) part, that's a mingw specific tweak not relevant to whether the function exists or not.)
Here this function is available for all architectues except i386. (mingw-w64 only supports i386, x86_64, arm, arm64, so it doesn't take any stance on e.g. IA64.)

Similarly the wine spec file shows this:

@ cdecl -arch=arm,x86_64,arm64 acosf(float) MSVCRT_acosf

That is, the function is explicitly available on these three architectures.

But then for the logbf case, things are actually different. The mingw def file contains this:

F_NON_I386(_logbf)
logbf

(These are symbols without the extra leading underscore which is prepended on cdecl functions on i386 though.)
The wine spec file:

@ cdecl -arch=arm,x86_64,arm64 _logbf(float) MSVCRT__logbf
@ stub logbf

This means that there's both a _logbf function (only on the three non-i386 arches) and a logbf function (on all arches). (The stub part only means that wine hasn't hooked it up to anything, probably because nobody has encountered a program using that function yet.)

If you want to look at what existed in older versions, pick e.g. msvcr100 or msvcr110, because msvcr120 actually already seems to have gotten most of the new functions that we're adding conditionally with hasPartialC99. For mingw-w64, those def files aren't merged into one common for all architectures, but are kept separately in the lib32 and lib64 directories next to lib-common.

264

Yes, logbf was available for x86_64 before, but wih this change, it only becomes available for the modern CRT. That is, I suggest changing || in the condition to && here. But as the _logbf name only exists for x86_64/arm/aarch64, I would suggest this:

// Unavailable for i386 on older crt versions, available for i386 on modern crts and on all crt versions for other architectures.
if (!hasPartialSP && !hasPartialC99)
  TLI.setUnavailable(LibFunc_logbf);
// On non-i386 versions, this function always exists, as _logbf.
// Modern crt versions also provide it under the name logbf, for all archs.
if (hasPartialSP)
 TLI.setAvailableWithName(LibFunc_logbf, "_logbf");

[evandro]

llvm/lib/Analysis/TargetLibraryInfo.cpp

264

I think that this gives me a plan of action: I'll commit this patch as is and commit another adding the remaining functions I find out after examining the information available in MinGW, keeping in mind that, to LLVM, MSVCRT and MinGW are different targets (specifically, MinGW using the GNU runtime). This way, should any problem arise later, it should be easy to narrow it down and fix it.

Thank you so very much.

[evandro]

Commited extra float C99 functions in rGf4a369596f7b.

[mstorsjo]

llvm/lib/Analysis/TargetLibraryInfo.cpp

264

Well, MSVC+MSVCRT and MinGW are different targets yes, but MinGW does try to describe the same actual DLLs from Microsoft.

A bit of backstory here: Traditionally, MinGW has linked to the old msvcrt.dll that is shipped with Windows (which is explicitly discouraged by Microsoft), in order to avoid relying on having to ship a CRT with the distributed apps. That DLL hasn't evolved much at all during the years and versions. In addition to this, MinGW does have listings of functions for the newer MSVC provided DLLs like msvcr100.dll, msvcr110.dll etc, but these aren't used by default. Recently though, mingw-w64 has gotten support for the new UCRT, and also support for setting this as the default version used.

So even if they're different targets in LLVM (and the MinGW target has to cope with the old discouraged and ancient msvcrt.dll), the MinGW def file for ucrtbase.dll and the other msvcr*.dll should be fairly accurate and corrent descriptions for what they contain even for a MSVC context. (There are a few MinGW specifics like having a few functions on their own added via a static library, but the def listings should be accurate despite this.)

llvm/lib/Analysis/TargetLibraryInfo.cpp

   }
 
   if (T.isOSWindows() && !T.isOSCygMing()) {
-    // Win32 does not support long double
+    bool is64 = (T.getArch() == Triple::aarch64 ||
+                 T.getArch() == Triple::x86_64);
+
+    // Win32 does not support float math functions, in general.
+    if (!is64) {
+      TLI.setUnavailable(LibFunc_acosf);
+      TLI.setUnavailable(LibFunc_asinf);
+      TLI.setUnavailable(LibFunc_atanf);
+      TLI.setUnavailable(LibFunc_atan2f);
+      TLI.setUnavailable(LibFunc_ceilf);
+      TLI.setUnavailable(LibFunc_cosf);
+      TLI.setUnavailable(LibFunc_coshf);
+      TLI.setUnavailable(LibFunc_expf);
+      TLI.setUnavailable(LibFunc_floorf);
+      TLI.setUnavailable(LibFunc_fmodf);
+      TLI.setUnavailable(LibFunc_logf);
+      TLI.setUnavailable(LibFunc_log10f);
+      TLI.setUnavailable(LibFunc_modff);
+      TLI.setUnavailable(LibFunc_powf);
+      TLI.setUnavailable(LibFunc_sinf);
+      TLI.setUnavailable(LibFunc_sinhf);
+      TLI.setUnavailable(LibFunc_sqrtf);
+      TLI.setUnavailable(LibFunc_tanf);
+      TLI.setUnavailable(LibFunc_tanhf);
+    }
+    TLI.setUnavailable(LibFunc_copysignf);
+    TLI.setUnavailable(LibFunc_fabsf);
+    TLI.setUnavailable(LibFunc_fmaxf);
+    TLI.setUnavailable(LibFunc_fminf);
+    TLI.setUnavailable(LibFunc_frexpf);
+    TLI.setUnavailable(LibFunc_ldexpf);
+
+    // Win32 does not support long double.
     TLI.setUnavailable(LibFunc_acosl);
     TLI.setUnavailable(LibFunc_asinl);
     TLI.setUnavailable(LibFunc_atanl);

     TLI.setUnavailable(LibFunc_cosl);
     TLI.setUnavailable(LibFunc_coshl);
     TLI.setUnavailable(LibFunc_expl);
-    TLI.setUnavailable(LibFunc_fabsf); // Win32 and Win64 both lack fabsf
     TLI.setUnavailable(LibFunc_fabsl);
     TLI.setUnavailable(LibFunc_floorl);
     TLI.setUnavailable(LibFunc_fmaxl);
     TLI.setUnavailable(LibFunc_fminl);
     TLI.setUnavailable(LibFunc_fmodl);
     TLI.setUnavailable(LibFunc_frexpl);
-    TLI.setUnavailable(LibFunc_ldexpf);
     TLI.setUnavailable(LibFunc_ldexpl);
     TLI.setUnavailable(LibFunc_logl);
+    TLI.setUnavailable(LibFunc_log10l);
     TLI.setUnavailable(LibFunc_modfl);
     TLI.setUnavailable(LibFunc_powl);
     TLI.setUnavailable(LibFunc_sinl);

     TLI.setUnavailable(LibFunc_tanl);
     TLI.setUnavailable(LibFunc_tanhl);
 
-    // Win32 only has C89 math
-    TLI.setUnavailable(LibFunc_acosh);
+    // Win32 does not support C89 math functions, in general.
+    // acosh
     TLI.setUnavailable(LibFunc_acoshf);
     TLI.setUnavailable(LibFunc_acoshl);
-    TLI.setUnavailable(LibFunc_asinh);
+    // asinh
     TLI.setUnavailable(LibFunc_asinhf);
     TLI.setUnavailable(LibFunc_asinhl);
-    TLI.setUnavailable(LibFunc_atanh);
+    // atanh
     TLI.setUnavailable(LibFunc_atanhf);
     TLI.setUnavailable(LibFunc_atanhl);
     TLI.setUnavailable(LibFunc_cabs);
     TLI.setUnavailable(LibFunc_cabsf);
     TLI.setUnavailable(LibFunc_cabsl);
-    TLI.setUnavailable(LibFunc_cbrt);
+    // cbrt
     TLI.setUnavailable(LibFunc_cbrtf);
     TLI.setUnavailable(LibFunc_cbrtl);
-    TLI.setUnavailable(LibFunc_exp2);
+    // exp2
     TLI.setUnavailable(LibFunc_exp2f);
     TLI.setUnavailable(LibFunc_exp2l);
-    TLI.setUnavailable(LibFunc_expm1);
+    // expm1
     TLI.setUnavailable(LibFunc_expm1f);
     TLI.setUnavailable(LibFunc_expm1l);
-    TLI.setUnavailable(LibFunc_log2);
-    TLI.setUnavailable(LibFunc_log2f);
-    TLI.setUnavailable(LibFunc_log2l);
-    TLI.setUnavailable(LibFunc_log1p);
+    // log1p
     TLI.setUnavailable(LibFunc_log1pf);
     TLI.setUnavailable(LibFunc_log1pl);
-    TLI.setUnavailable(LibFunc_logb);
-    TLI.setUnavailable(LibFunc_logbf);
+    // log2
+    TLI.setUnavailable(LibFunc_log2f);
+    TLI.setUnavailable(LibFunc_log2l);
+    // logb
+    if (!is64)
+      TLI.setUnavailable(LibFunc_logbf);
     TLI.setUnavailable(LibFunc_logbl);
-    TLI.setUnavailable(LibFunc_nearbyint);
+    // nearbyint
     TLI.setUnavailable(LibFunc_nearbyintf);
     TLI.setUnavailable(LibFunc_nearbyintl);
-    TLI.setUnavailable(LibFunc_rint);
+    // rint
     TLI.setUnavailable(LibFunc_rintf);
     TLI.setUnavailable(LibFunc_rintl);
-    TLI.setUnavailable(LibFunc_round);
+    // round
     TLI.setUnavailable(LibFunc_roundf);
     TLI.setUnavailable(LibFunc_roundl);
-    TLI.setUnavailable(LibFunc_trunc);
+    // trunc
     TLI.setUnavailable(LibFunc_truncf);
     TLI.setUnavailable(LibFunc_truncl);
 
-    // Win32 provides some C99 math with mangled names
+    // Win32 supports some C89 and C99 math functions, but with mangled names.
     TLI.setAvailableWithName(LibFunc_copysign, "_copysign");
+    if (is64)
+      TLI.setAvailableWithName(LibFunc_logbf, "_logbf");
 
-    if (T.getArch() == Triple::x86) {
-      // Win32 on x86 implements single-precision math functions as macros
-      TLI.setUnavailable(LibFunc_acosf);
-      TLI.setUnavailable(LibFunc_asinf);
-      TLI.setUnavailable(LibFunc_atanf);
-      TLI.setUnavailable(LibFunc_atan2f);
-      TLI.setUnavailable(LibFunc_ceilf);
-      TLI.setUnavailable(LibFunc_copysignf);
-      TLI.setUnavailable(LibFunc_cosf);
-      TLI.setUnavailable(LibFunc_coshf);
-      TLI.setUnavailable(LibFunc_expf);
-      TLI.setUnavailable(LibFunc_floorf);
-      TLI.setUnavailable(LibFunc_fminf);
-      TLI.setUnavailable(LibFunc_fmaxf);
-      TLI.setUnavailable(LibFunc_fmodf);
-      TLI.setUnavailable(LibFunc_logf);
-      TLI.setUnavailable(LibFunc_log10f);
-      TLI.setUnavailable(LibFunc_modff);
-      TLI.setUnavailable(LibFunc_powf);
-      TLI.setUnavailable(LibFunc_sinf);
-      TLI.setUnavailable(LibFunc_sinhf);
-      TLI.setUnavailable(LibFunc_sqrtf);
-      TLI.setUnavailable(LibFunc_tanf);
-      TLI.setUnavailable(LibFunc_tanhf);
-    }
+    // Win32 does not support these C99 functions.
+    TLI.setUnavailable(LibFunc_atoll);
+    TLI.setUnavailable(LibFunc_llabs);
 
-    // Win32 does *not* provide these functions, but they are
+    // Win32 does not support these functions, but they are
     // generally available on POSIX-compliant systems:
     TLI.setUnavailable(LibFunc_access);
     TLI.setUnavailable(LibFunc_bcmp);

     TLI.setUnavailable(LibFunc_utime);
     TLI.setUnavailable(LibFunc_utimes);
     TLI.setUnavailable(LibFunc_write);
-
-    // Win32 does *not* provide provide these functions, but they are
-    // specified by C99:
-    TLI.setUnavailable(LibFunc_atoll);
-    TLI.setUnavailable(LibFunc_frexpf);
-    TLI.setUnavailable(LibFunc_llabs);
   }
 
   switch (T.getOS()) {

llvm/test/Transforms/InstCombine/double-float-shrink-1.ll

 
 define float @logb_test1(float %f)   {
 ; CHECK-LABEL: @logb_test1(
-; LINUX-NEXT:    [[LOGBF:%.*]] = call fast float @logbf(float [[F:%.*]])
-; LINUX-NEXT:    ret float [[LOGBF]]
-; WIN96:         [[LOGBF:%.*]] = call fast double @logb(double [[F:%.*]])
+; LIN64-NEXT:    [[LOGBF:%.*]] = call fast float @logbf(float [[F:%.*]])
+; LIN64-NEXT:    ret float [[LOGBF]]
+; WIN32:         [[LOGBF:%.*]] = call fast double @logb(double [[F:%.*]])
 ;
   %conv = fpext float %f to double
   %call = call fast double @logb(double %conv)

 ; flags are propagated for shrunken *binary* double FP calls.
 define float @max1(float %a, float %b) {
 ; CHECK-LABEL: @max1(
-; LIN64-NEXT:    [[FMAXF:%.*]] = call arcp float @fmaxf(float [[A:%.*]], float [[B:%.*]])
-; LIN64-NEXT:    ret float [[FMAXF]]
-; WIN32:         [[FMAXF:%.*]] = call arcp double @fmax(double [[A:%.*]], double [[B:%.*]])
+; LINUX-NEXT:    [[FMAXF:%.*]] = call arcp float @fmaxf(float [[A:%.*]], float [[B:%.*]])
+; LINUX-NEXT:    ret float [[FMAXF]]
+; WIN96:         [[FMAXF:%.*]] = call arcp double @fmax(double [[A:%.*]], double [[B:%.*]])
 ;
   %c = fpext float %a to double
   %d = fpext float %b to double

llvm/test/Transforms/InstCombine/double-float-shrink-2.ll

 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
-; RUN: opt < %s -instcombine -S -mtriple "i386-pc-linux"     | FileCheck --check-prefixes=CHECK,DO-SIMPLIFY %s
-; RUN: opt < %s -instcombine -S -mtriple "i386-pc-win32"     | FileCheck --check-prefixes=CHECK,DONT-SIMPLIFY %s
-; RUN: opt < %s -instcombine -S -mtriple "x86_64-pc-win32"   | FileCheck --check-prefixes=CHECK,C89-SIMPLIFY %s
-; RUN: opt < %s -instcombine -S -mtriple "i386-pc-mingw32"   | FileCheck --check-prefixes=CHECK,DO-SIMPLIFY %s
-; RUN: opt < %s -instcombine -S -mtriple "x86_64-pc-mingw32" | FileCheck --check-prefixes=CHECK,DO-SIMPLIFY %s
-; RUN: opt < %s -instcombine -S -mtriple "sparc-sun-solaris" | FileCheck --check-prefixes=CHECK,DO-SIMPLIFY %s
+; RUN: opt < %s -instcombine -S -mtriple "i386-pc-linux"     | FileCheck %s
+; RUN: opt < %s -instcombine -S -mtriple "i386-pc-win32"     | FileCheck %s
+; RUN: opt < %s -instcombine -S -mtriple "x86_64-pc-win32"   | FileCheck %s
+; RUN: opt < %s -instcombine -S -mtriple "i386-pc-mingw32"   | FileCheck %s
+; RUN: opt < %s -instcombine -S -mtriple "x86_64-pc-mingw32" | FileCheck %s
+; RUN: opt < %s -instcombine -S -mtriple "sparc-sun-solaris" | FileCheck %s
 ; RUN: opt < %s -instcombine -S -mtriple "x86_64-pc-win32" -enable-debugify 2>&1 | FileCheck --check-prefix=DBG-VALID %s
 
 declare double @floor(double)

 
 define float @test_shrink_libcall_round(float %C) {
 ; CHECK-LABEL: @test_shrink_libcall_round(
-
-; DO-SIMPLIFY-NEXT:    [[F:%.*]] = call float @llvm.round.f32(float [[C:%.*]])
-; DO-SIMPLIFY-NEXT:    ret float [[F]]
-;
-; DONT-SIMPLIFY-NEXT:    [[D:%.*]] = fpext float [[C:%.*]] to double
-; DONT-SIMPLIFY-NEXT:    [[E:%.*]] = call double @round(double [[D]])
-; DONT-SIMPLIFY-NEXT:    [[F:%.*]] = fptrunc double [[E]] to float
-; DONT-SIMPLIFY-NEXT:    ret float [[F]]
-;
-; C89-SIMPLIFY-NEXT:    [[D:%.*]] = fpext float [[C:%.*]] to double
-; C89-SIMPLIFY-NEXT:    [[E:%.*]] = call double @round(double [[D]])
-; C89-SIMPLIFY-NEXT:    [[F:%.*]] = fptrunc double [[E]] to float
-; C89-SIMPLIFY-NEXT:    ret float [[F]]
+; CHECK-NEXT:    [[F:%.*]] = call float @llvm.round.f32(float [[C:%.*]])
+; CHECK-NEXT:    ret float [[F]]
 ;
   %D = fpext float %C to double
   ; --> roundf

 
 define float @test_shrink_libcall_nearbyint(float %C) {
 ; CHECK-LABEL: @test_shrink_libcall_nearbyint(
-
-; DO-SIMPLIFY-NEXT:    [[F:%.*]] = call float @llvm.nearbyint.f32(float [[C:%.*]])
-; DO-SIMPLIFY-NEXT:    ret float [[F]]
-;
-; DONT-SIMPLIFY-NEXT:    [[D:%.*]] = fpext float [[C:%.*]] to double
-; DONT-SIMPLIFY-NEXT:    [[E:%.*]] = call double @nearbyint(double [[D]])
-; DONT-SIMPLIFY-NEXT:    [[F:%.*]] = fptrunc double [[E]] to float
-; DONT-SIMPLIFY-NEXT:    ret float [[F]]
-;
-; C89-SIMPLIFY-NEXT:    [[D:%.*]] = fpext float [[C:%.*]] to double
-; C89-SIMPLIFY-NEXT:    [[E:%.*]] = call double @nearbyint(double [[D]])
-; C89-SIMPLIFY-NEXT:    [[F:%.*]] = fptrunc double [[E]] to float
-; C89-SIMPLIFY-NEXT:    ret float [[F]]
+; CHECK-NEXT:    [[F:%.*]] = call float @llvm.nearbyint.f32(float [[C:%.*]])
+; CHECK-NEXT:    ret float [[F]]
 ;
   %D = fpext float %C to double
   ; --> nearbyintf

 
 define float @test_shrink_libcall_trunc(float %C) {
 ; CHECK-LABEL: @test_shrink_libcall_trunc(
-
-; DO-SIMPLIFY-NEXT:    [[F:%.*]] = call float @llvm.trunc.f32(float [[C:%.*]])
-; DO-SIMPLIFY-NEXT:    ret float [[F]]
-;
-; DONT-SIMPLIFY-NEXT:    [[D:%.*]] = fpext float [[C:%.*]] to double
-; DONT-SIMPLIFY-NEXT:    [[E:%.*]] = call double @trunc(double [[D]])
-; DONT-SIMPLIFY-NEXT:    [[F:%.*]] = fptrunc double [[E]] to float
-; DONT-SIMPLIFY-NEXT:    ret float [[F]]
-;
-; C89-SIMPLIFY-NEXT:    [[D:%.*]] = fpext float [[C:%.*]] to double
-; C89-SIMPLIFY-NEXT:    [[E:%.*]] = call double @trunc(double [[D]])
-; C89-SIMPLIFY-NEXT:    [[F:%.*]] = fptrunc double [[E]] to float
-; C89-SIMPLIFY-NEXT:    ret float [[F]]
+; CHECK-NEXT:    [[F:%.*]] = call float @llvm.trunc.f32(float [[C:%.*]])
+; CHECK-NEXT:    ret float [[F]]
 ;
   %D = fpext float %C to double
   ; --> truncf

llvm/test/Transforms/InstCombine/pow-1.ll

 
 define double @test_simplify3n(double %x) {
 ; CHECK-LABEL: @test_simplify3n(
-; ANY-NEXT:    [[MUL:%.*]] = fmul double [[X:%.*]], -2.000000e+00
-; ANY-NEXT:    [[EXP2:%.*]] = call double @exp2(double [[MUL]]) [[NUW_RO]]
-; ANY-NEXT:    ret double [[EXP2]]
-; WIN-NEXT:    [[POW:%.*]] = call double @pow(double 2.500000e-01, double [[X:%.*]])
-; WIN-NEXT:    ret double [[POW]]
+; CHECK-NEXT:  [[MUL:%.*]] = fmul double [[X:%.*]], -2.000000e+00
+; CHECK-NEXT:  [[EXP2:%.*]] = call double @exp2(double [[MUL]]) [[NUW_RO:#[0-9]+]]
+; CHECK-NEXT:  ret double [[EXP2]]
 ;
   %retval = call double @pow(double 0.25, double %x)
   ret double %retval

 
 define double @test_simplify4(double %x) {
 ; CHECK-LABEL: @test_simplify4(
-; ANY-NEXT:    [[EXP2:%.*]] = call double @exp2(double [[X:%.*]]) [[NUW_RO]]
-; ANY-NEXT:    ret double [[EXP2]]
-; WIN-NEXT:    [[POW:%.*]] = call double @pow(double 2.000000e+00, double [[X:%.*]])
-; WIN-NEXT:    ret double [[POW]]
+; CHECK-NEXT:  [[EXP2:%.*]] = call double @exp2(double [[X:%.*]]) [[NUW_RO]]
+; CHECK-NEXT:  ret double [[EXP2]]
 ;
   %retval = call double @pow(double 2.0, double %x)
   ret double %retval

 define float @test_simplify7(float %x) {
 ; CHECK-LABEL: @test_simplify7(
 ; ANY-NEXT:    [[SQRTF:%.*]] = call float @sqrtf(float [[X:%.*]]) [[NUW_RO]]
-; WIN-NEXT:    [[SQRTF:%.*]] = call float @sqrtf(float [[X:%.*]]) [[NUW_RO:#[0-9]+]]
+; WIN-NEXT:    [[SQRTF:%.*]] = call float @sqrtf(float [[X:%.*]]) [[NUW_RO]]
 ; CHECK-NEXT:  [[ABS:%.*]] = call float @llvm.fabs.f32(float [[SQRTF]])
 ; CHECK-NEXT:  [[ISINF:%.*]] = fcmp oeq float [[X]], 0xFFF0000000000000
 ; CHECK-NEXT:  [[TMP1:%.*]] = select i1 [[ISINF]], float 0x7FF0000000000000, float [[ABS]]

llvm/test/Transforms/InstCombine/win-math.ll

-; RUN: opt -O2 -S -mtriple=i386-pc-win32 < %s     | FileCheck %s --check-prefixes=CHECK,WIN32
-; RUN: opt -O2 -S -mtriple=x86_64-pc-win32 < %s   | FileCheck %s --check-prefixes=CHECK,WIN64
-; RUN: opt -O2 -S -mtriple=i386-pc-mingw32 < %s   | FileCheck %s --check-prefixes=CHECK,MINGW32
-; RUN: opt -O2 -S -mtriple=x86_64-pc-mingw32 < %s | FileCheck %s --check-prefixes=CHECK,MINGW64
+; RUN: opt < %s -O2 -S -mtriple=i386-pc-win32     | FileCheck %s --check-prefixes=CHECK,WIN32
+; RUN: opt < %s -O2 -S -mtriple=x86_64-pc-win32   | FileCheck %s --check-prefixes=CHECK,WIN64
+; RUN: opt < %s -O2 -S -mtriple=i386-pc-mingw32   | FileCheck %s --check-prefixes=CHECK,MINGW32
+; RUN: opt < %s -O2 -S -mtriple=x86_64-pc-mingw32 | FileCheck %s --check-prefixes=CHECK,MINGW64
 
 ; x86 win32 msvcrt does not provide entry points for single-precision libm.
-; x86-64 win32 msvcrt does (except for fabsf)
-; msvcrt does not provide C99 math, but mingw32 does.
+; x86-64 win32 msvcrt does, but with exceptions
+; msvcrt does not provide all of C99 math, but mingw32 does.
 
 declare double @acos(double %x)
 define float @float_acos(float %x) nounwind readnone {

     ret float %3
 }
 
+declare double @logb(double %x)
+define float @float_logb(float %x) nounwind readnone {
+; CHECK-LABEL: @float_logb(
+; WIN32-NOT: float @logbf
+; WIN32: double @logb
+; WIN64-NOT: float @logbf
+; WIN64: double @logb
+    %1 = fpext float %x to double
+    %2 = call double @logb(double %1)
+    %3 = fptrunc double %2 to float
+    ret float %3
+}
+
 declare double @pow(double %x, double %y)
 define float @float_pow(float %x, float %y) nounwind readnone {
 ; CHECK-LABEL: @float_pow(

     ret float %3
 }
 
-; win32 does not have round; mingw32 does
+; win32 does not have roundf; mingw32 does
 declare double @round(double %x)
 define float @float_round(float %x) nounwind readnone {
 ; CHECK-LABEL: @float_round(
-; WIN32-NOT: float @roundf
-; WIN32: double @round
-; WIN64-NOT: float @roundf
-; WIN64: double @round
+; WIN32-NOT: double @round
+; WIN32: float @llvm.round.f32
+; WIN64-NOT: double @round
+; WIN64: float @llvm.round.f32
 ; MINGW32-NOT: double @round
 ; MINGW32: float @llvm.round.f32
 ; MINGW64-NOT: double @round

 
 declare float @powf(float, float)
 
-; win32 lacks sqrtf&fabsf, win64 lacks fabsf, but
+; win32 lacks sqrtf & fabsf, win64 lacks fabsf, but
 ; calls to the intrinsics can be emitted instead.
 define float @float_powsqrt(float %x) nounwind readnone {
 ; CHECK-LABEL: @float_powsqrt(