[libc-commits] [libc] [reland][libc] Remove unnecessary `FPBits` functions and properties (PR #79128)

[Nick Desaulniers via libc-commits]

nickdesaulniers wrote:

All great ideas.

> Have a test covering the fact that we do indeed ship the C functions,

So, some `.c` files under libc/test/ rather than just `.cpp` files? I assume GTEST (or our variant) works with C and not just C++?

Was C vs C++ one of the related issues in this case?

> Have most of the build bots as part of the precommit check in github,

Yeah this is a good idea.  The tradeoff between "should this be in presubmit vs post submit" is usually latency.  Even if we just did builds in presubmit and then ran the tests in post submit, that might be the right balance.  I think the presubmit bots configurations are somewhere in https://github.com/llvm/llvm-zorg; we can play with moving more checks into presubmit.

> Have more build bots covering more architectures (GPU, Fuchsia)

So we do have the Fuchsia build bot spot issues, though IDK how to find it on lab.llvm.org...is it just https://lab.llvm.org/buildbot/#/builders/98 (@petrhosek )?  Maybe we should look into adding a dedicated build of just llvm-libc just for Fuchsia?

What about GPU builds. Do we have GPU builds of llvm-libc on lab.llvm.org @jhuber6 ? (And forgive my ignorance)

> Having faster cross-compilation would definitely help on the latency side of things.

Yeah, with enable runtimes, I bet I can BUILD arm32 faster on an x86_64 host than on the arm32 build bot itself.  For running the unit tests, we need to explore qemu.  I'd also bet that running the unit tests in an arm32 vm in qemu on an x86_64 host is also faster than running the tests natively on the arm32 build bot.

> I had no signal that it was broken but my apologies for the breakage nonetheless.

Ah, no worries! Thanks for brainstorming with me ways in which we can improve our development processes so that we can all go faster.

https://github.com/llvm/llvm-project/pull/79128