[llvm-dev] A libc in LLVM

Stan Shebs via llvm-dev
Fri, 28 Jun 2019 18:51:52 -0000

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