From this thread on LKML: https://lore.kernel.org/lkml/76071c24-ec6f-7f7a-4172-082bd574d581@zytor.com/ It was noted that for hosted environments that don't quite have a full libc implementation, that they can lean on -fno-builtin-* flags in Clang to avoid libcall optimizations where LLVM would emit calls to * which the environment did not provide definitions of (though this differs from GCC's behavior, see these three posts from Arvind that are a really fantastic analysis: 1. https://lore.kernel.org/lkml/20200818214146.GA3196105@rani.riverdale.lan/ 2. https://lore.kernel.org/lkml/20200820175617.GA604994@rani.riverdale.lan/ 3. https://lore.kernel.org/lkml/20200821172935.GA1411923@rani.riverdale.lan/ ). Kernel developer H. Peter Anvin points out it would be helpful for embedded environments that would use -ffreestanding to opt out of all such libcall optimizations, to be able to opt back in (rather than opting out via -fno-builtin-*) to certain libcall optimizations when the otherwise freestanding implementation provided such symbols with matching semantics (ie. the Linux kernel). It was suggested that listing supported functions in the environment via #pragma's (maybe in a header for codebase-wide inclusion) might be helpful. In particular, I think it would slot in nicely in Clang to provide -fbuiltin-* support (there's rules in tablegen to generate support for -f-* and -fno-* from one rule). So `-ffreestanding -fbuiltin-strcpy` would be "disable all libcall optimizations except related to transforming other libcalls into strcpy, denoting the target supported no other builtins than strcpy (and the always required mem* family). It's not an immediate need, more so a curiosity that it's easy to opt out of libcall optimizations, but not necessarily opt in.
Another suggestion from that thread which seemed potentially viable was adding a "-fno-synthesize-libc-calls" flag: basically, assume calls to known functions have the libc semantics, but don't transform those calls to refer to other libc functions. The end result is a bit weird semantically: conventionally, whether libc usable is sort of a binary choice. But it would follow the longstanding kernel preference for "do what I mean" semantics without requiring the user to actually list out the relevant functions.