https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121419
--- Comment #6 from David Faust <david.faust at oracle dot com> --- Sorry this fell off my plate for a while. We will have to add some new optabs in the bpf backend. Don't think there's a way around that for now. And likely not just for clz as is the problem here, but also ctz, ffs, popcount, etc. We should never emit libcalls since the BPF .o won't ever be linked against libgcc. (There might be some possibility here with the "static linking" BPF commands but I guess that would require the application code to make bpf syscalls to link in libgcc. Could be investigated further.) Unfortunately, afaics we'll need to effectively define optabs for _everything_ implemented in libgcc to ensure we never emit libcalls, which is also gonna be error prone. See prior miscompilations in the BPF memset expansion. On top of that it's wasteful since the resulting BPF bytecode is almost certainly just going to get JITted back to an architecture with a single instruction clz - which now won't be used since we've expanded the operation. Seems like it might eventually be better to implement things like this as a sort of "JIT builtin" in the arch-specific BPF JITs.
