{"id":36915,"date":"2026-09-16T22:09:50","date_gmt":"2026-09-16T22:09:50","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=36915"},"modified":"2026-09-16T22:09:50","modified_gmt":"2026-09-16T22:09:50","slug":"bringing-correctly-rounded-math-to-production-with-llvm-libc","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/bringing-correctly-rounded-math-to-production-with-llvm-libc\/","title":{"rendered":"Bringing Correctly Rounded Math to Production with LLVM-libc"},"content":{"rendered":"

As we mentioned in the last cmath blog post<\/a>, MSVC is using LLVM-libc for compile-time evaluation and runtime execution of math functions when \/Zc:cmath<\/code> is enabled. I invited LLVM-libc contributors Michael Jones and Tue Ly to write a guest blog post about how they\u2019ve achieved what they\u2019ve achieved. This is that blog post! I hope you enjoy it. I learned a lot from reading it, even after having spent a lot of time in this area.<\/p>\n

– Cody, Microsoft C++ Compiler Frontend Engineer<\/p><\/blockquote>\n

Hi, I’m Michael Jones, the lead maintainer for LLVM-libc. Cody invited me and our math lead, Tue Ly, to write a guest post about LLVM-libc’s math functions. Tue and I work on LLVM-libc at Google, where we’ve been working on the project for about five years now.<\/p>\n

I’m going to talk a bit about the history and philosophy of LLVM-libc, then Tue will do a deeper dive into how and why our math functions are so good. I’m really excited for you all to use the code we’ve been working on, and thanks to Cody for putting all of this together!<\/p>\n

1. libc as a Library<\/h2>\n

Generally, implementations of the C standard library (libc<\/code>) are written for a specific target. They are usually monolithic libraries that are closely tied to the OS interface they’re based on. They also don’t make any effort to keep individual functions separate, which makes them difficult to break into smaller chunks.<\/p>\n

In 2019, LLVM-libc was started with a different design philosophy. The focus was on portability, modularity, and writing clean C++ that could be reused. The original design describes this as writing “libc as a library”, meaning that it would be much closer to an idiomatic C\/C++ library. From the beginning, there has been a separation between the OS interface layer and the public interface, as well as making each individual function independent. Portability has also involved avoiding assembly except where absolutely necessary, which has the added benefit of enabling the compiler to make deeper optimizations.<\/p>\n

Building on the modular design, I started Project Hand-in-Hand which allowed LLVM’s libc++ to use the same float-to-string conversion code as LLVM-libc. Other LLVM projects have also started to integrate LLVM-libc’s code, such as OpenMP using the printf core and compiler-rt using the software floating point support. Soon both clang and MSVC will be using LLVM-libc’s math library for constexpr evaluation, but what makes LLVM-libc’s math suitable for compiler use?<\/p>\n

2. libm as an Opportunity<\/h2>\n

I feel like I know more than the average programmer about floating point numbers, but I would not consider myself an expert. Tue Ly is definitely an expert, with the experience and credentials to prove it. He was the one who designed LLVM-libc’s math library from the ground up, and it was his idea to make it correctly rounded for all rounding modes. This turned out to be hugely important to Google for much the same reason it’s important to Microsoft: different versions of your math library returning different results can have disastrous consequences when working with heterogeneous distributed systems. I’ll let Tue go into the details of exactly how the math functions are still performant while being so accurate, as well as the path to get there.<\/p>\n

3. The “Dark Magic” of libm and Why Consistency Demands Correct Rounding<\/h2>\n

Thanks, Michael! And thanks to Cody for inviting us to contribute to this series.<\/p>\n

In the previous blog post, Cody laid out the four dimensions users care about when it comes to math libraries: Stability<\/strong>,\u00a0Accuracy<\/strong>, Consistency<\/strong>, and\u00a0Performance<\/strong>\u00a0(or, in Cody’s words,\u00a0“Numbers go brrr”<\/em>).<\/p>\n

Floating-point math in software is often treated like dark magic. When developers see different results across platforms or compilers, they often shrug and say,\u00a0“Well, floating-point is inexact.”<\/em>\u00a0But inexact representation does not mean mathematical operations have to be non-deterministic.<\/p>\n

Traditional math libraries (libm<\/code>) frequently produce different results across platforms and versions. In production systems, these differences cause real issues:<\/p>\n