[llvm-dev] A libc in LLVM

[Stan Shebs via llvm-dev]

On Fri, Jun 28, 2019 at 11:58 AM Stephen Canon via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> On Jun 26, 2019, at 2:20 PM, Siva Chandra via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> [...]
>
> 1. You could partially work around this by adding builtins and an extensive conformance suite, making your implementations fragile to compiler optimization but detecting the breakages immediately.
> 2. You could do the work of precisely modeling the floating-point environment.
> 3. You could simply declare that you are not going to care about flags at all, which is fine for 99% of users, but is a clear break from relevant standards (and would make your libc unable to be adopted by some platform maintainers).
> 4. You could implement significant pieces of the math library in assembly.

I'm no math expert, but I tangle with clang vs glibc's math code
regularly, and have discussed all this with Siva.

It's too early to say exactly what the implementation will look like,
but I anticipate it will be a combination of 1) and 2).  There's
really no alternative to having a mode that does accurate flag
handling, but if the compiler has both library sources and call sites
in hand, it should be able to determine whether it needs to include,
say, underflow handling, and only compile in those parts.  We've
handicapped ourselves somewhat by having shifted to a model where the
library functions are black boxes because of dynamic linking, and I
think we can do better than just introducing more and more ifuncs or
whatever.

I also expect there will be more work to do in the compiler, both for
builtins and for additional optimizations, and to me that is part of
the rationale to put the libc project under LLVM in general.  There
won't be any secrets - if GCC folks want to try their hand at
compiling this libc, they're welcome to it - but there will be some
opportunities to co-develop library code that takes advantage of new
compiler abilities and vice versa.

> - For most platforms, there are significant performance wins available for some of the core strings and memory functions using assembly, even as compared to the best compiler auto-vectorization output. There are a few reasons for this, but one of the major ones is that—in assembly, on most architectures—we can safely do aligned memory accesses that are partially outside the buffer that has been passed in, and mask off or ignore the bytes that are invalid. This is a hugely significant optimization for edging around core vector loops, and it’s simply unavailable in C and C++ because of the abstract memory models they define. A compiler could do this for you automatically, but this is not yet implemented in LLVM (and you don’t want to be tightly coupled to LLVM, anyway?) In practice, on many systems, the small-buffer case dominates usage for these functions, so getting the most efficient edging code is basically the only thing that matters.

Google does have a little experience in this area, mem* being the libc
functions that perennially show up at the top of fleetwide performance
profiles.  (Lots of protobufs to move, I guess. :-) )  I imagine there
will be both assembly and high-level versions in libc, and it will be
the compiler's challenge to meet or beat the assembly code.


>
> 1. Are you going to teach LLVM to perform these optimizations? If so, awesome, but this is not at all a small project—you’re not just fixing an isolated perf bug, you’re fundamentally reworking autovectorization. What about other compilers?
> 2. Are you going to simply write off performance in these cases and let the autovectorizer do what it does?
> 3. Will you use assembly instead purely for optimization purposes?
>
> A bunch of other questions will probably come to me around the math library, but I would encourage you to think very carefully about what specifications you want to have for a libm before you start building one. All that said, I think having more libc implementations is great, but I would be very careful to define what design tradeoffs you’re making around these choices and to what spec(s) you plan to conform, and why they necessitate a new libc rather than adapting an existing one.
>
> – Steve
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev