a few weeks ago i had my first pull request merged into the llvm project. refactoring bf16div to be header-only and part of the shared math library. nothing glamorous, but the process taught me more than the change itself.

the context

llvm libc has an ongoing effort (#147386) to make higher math functions header-only. the motivation is C++23 constexpr math support: if the implementation lives in a header, the compiler can evaluate it at compile time. bf16div, the bfloat16 division function, was still a standalone .cpp file with its logic inlined directly. it needed to be extracted into src/__support/math/.

what the change actually does

before the patch, bf16div.cpp directly called fputil::generic::div<bfloat16>(x, y) and dragged in a handful of includes itself. the entrypoint's CMake target listed all the individual dependencies.

after:

// libc/src/__support/math/bf16div.h
LIBC_INLINE bfloat16 bf16div(double x, double y) {
  return fputil::generic::div<bfloat16>(x, y);
}

// libc/src/math/generic/bf16div.cpp
LLVM_LIBC_FUNCTION(bfloat16, bf16div, (double x, double y)) {
  return math::bf16div(x, y);
}

the entrypoint becomes a thin wrapper. the logic lives in the header. the cmake entrypoint now depends on libc.src.__support.math.bf16div instead of enumerating the underlying headers. bazel gets a matching libc_support_library + libc_math_function pair.

the review process

my first submission had the constexpr qualifier added to fputil::generic::div itself. the reviewer, bassiounix, asked me to look at recently merged PRs and spot the pattern. turns out they weren't adding constexpr to the underlying generic template, that's a much bigger change with wider impact. just the wrapper stays non-constexpr for now. i reverted that, cleaned up redundant includes in the cpp file, fixed an alphabetical ordering issue in a test cmake file, and accidentally deleted a log2 test case i had to restore. not my finest hour.

second round: "LGTM overall. please format the bazel build file." formatted it. third round: approved and merged.

four commits total across two force-pushes and a merge-from-main. the whole thing took about a month from open to merge, mostly just waiting between review cycles.

PR: llvm/llvm-project#181400
Merged: March 13, 2026