On Tue, Aug 30, 2022 at 3:53 AM Rob Landley <[email protected]> wrote:
> On 8/29/22 19:17, enh wrote: > > On Sat, Aug 27, 2022 at 1:59 AM Rob Landley <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 8/26/22 18:11, enh via Toybox wrote: > > > have you tried? the llvm-libc folks are effectively starting from > scratch > > > ( > https://github.com/llvm/llvm-project/blob/main/libc/src/stdlib/qsort.cpp, > and > > > > Sigh. I had honestly hoped that particular https://xkcd.com/927/ > had died during > > the pandemic, or at least quiesced like klibc and newlib. Last I'd > heard it > > mentioned was > > > https://hub.packtpub.com/google-proposes-a-libc-in-llvm-rich-felker-of-musl-libc-thinks-its-a-very-bad-idea/ > > > > i think you're thinking of the wrong axis here. i think far more > interesting > > than OS is cpu architecture. right now there's no one place everyone can > pull > > from that has optimized code for arm/x86/etc. even getting the different > parts > > of arm or intel to coordinate can be hard ("oh, yeah, we own math > libraries, but > > only for the _server_" --- not throwing any stones; i work for a company > with > > 100k employees too, and that's just the way large organizations end up). > llvm is > > one of the few pieces of common ground (and it's not GPL, so it doesn't > have the > > "oh, shit, we worked on glibc but didn't realize you couldn't take code > from > > there" problem). > > > > so for string/memory, math, etc, i actually think it's a good idea. (i > reserve > > the right to change my mind when they want to break "memcpy == memmove", > say, > > but that's fine --- they're not making me take any code i don't actually > want. > > and i won't be able to take any code that involves ABI anyway, since i > can't > > change ABI.) > > > > hell, even if it just gives the three(+) BSDs a common source to share > from, > > that would be a step in the right direction! > > I defer to Rich Felker and Jeff Dionne on this one. I trust their domain > expertise (Jeff knows hardware and Rich cares far more about IEEE floating > point > compatibility details than I'm likely to ever understand). If either of > them > thinks this sounds like a good idea. then I accept being wrong here. > > But a significant problem I've personally had is that llvm's version of > libgcc.a > is messy to the point of being almost uncompilable. (You may remember the > thread > from a year ago starting at > > http://lists.landley.net/pipermail/toybox-landley.net/2021-August/020537.html > .) > If they haven't managed a reasonable libcc yet, how are they going to do a > good > job with libc? > > And logically the assembly optimized stuff would be more libcc.a than > libc.a, > because the things that really need polishing wind up inlined by the > compiler > anyway as "builtins": > i actually think this is one of the stronger arguments for llvm-libc --- bionic already outsources all libm functions that _have_ a builtin (by having a one-liner that inlines the builtin) to ensure consistency here. and i'd rather have arm/intel contributing to llvm in a way that can potentially be inlined as a builtin than have to keep updating llvm _and_ https://github.com/ARM-software/optimized-routines _and_ hoping that someone at intel remembers bionic (and everyone else) and doesn't just work with glibc (say). > https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html > > So it's conceivable libcc could eat libm (as the above builtins basically > already have), but a quick glance at posix shows libc is full of stuff like > getservent(), getpeername(), globfree(), gmtime_r()... Signing up to > produce an > OS-portable version of psiginfo() or defining what should and should not be > included in a given regcomp/regexec implementation seems a VERY different > mandate than "here's the most optimal strcmp() for tiger lake". And then > you > either choose to have your new libc NOT to go beyond that into man 2 > unshare > (missing functionality), or have linux vs bsd incompatiblity, or resolve > that > incompatibility yourself... > yeah, i don't know what their plans are there, and anything with ABI is inherently uninteresting to me because i'm already stuck with a historic "mostly BSD-ish" ABI. > What you want them to do doesn't sound to me like what they're trying to > do. An > LD_PRELOAD that goes before libc.so to provide optimized stuff might be > interesting, and having libcc provide that semidigested AST format for LTO > inlines so your builtins list is dynamic would be novel. that's a surprising stance from the person who likes static binaries more than anyone else i know :-) (i know glibc has gone the LD_PRELOAD kind of route for this stuff, but bionic's gone with ifuncs. that seems like the best trade-off for us. there are reasons why SoC vendors might want to be able to substitute their own routines, but -- having been there before back in the arm32 days where everyone was shipping their own string/memory routines -- that was a disaster for correctness and compatibility. _i_ wouldn't want to go down that path again, and i suspect app developers wouldn't either. even though CTS has a lot more tests now, it's inherently easier to catch regressions than it is to catch novel ways to break things.) fwiw, bionic _already_ gets its arm/arm64 optimized string/memory routines (and some of its math) from https://github.com/ARM-software/optimized-routines so there's a lot of precedent here. (for bionic, at least. like i said, each the bsds struggles to stay in sync with the other two bsds; in my experience there can be more divergence between bsds than there is between macos and freebsd, which is its major upstream.) > But as soon as this > thing provides its own malloc() "there can be only one" and it's Queen and > lightshows time. > not unless you build and ship _their_ malloc. by that argument bionic can't use as much open/net/free-bsd code as it does, which is demonstrably false :-) > Rob >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
