enh-google wrote: > > > Typically we don't bother to implement these unless libc starts using > > > these, or needs them. Making builtins for these functions without the > > > library needs them is kinda silly. > > > DO we have a request for these coming from the libc maintainers? > > > > > > I think they're important for two reasons: 1) we're going to want constexpr > > support for these for the same reason we want constexpr support for > > `strlen` in C so defining them as recognized library builtins is the way we > > do that, and 2) I think libc is going to want to have full support for > > bit-precise integer types and that's easier to support from a builtin > > currently. That said, CC @michaelrj-google for additional opinions > > From the libc side having these builtins would be handy for both of the > reasons Aaron mentioned. For optimization it would be helpful if the compiler > could replace the libcall with a builtin, since things like `leading_zeros` > can sometimes be reduced to a single instruction. Actually calling these bit > functions as functions is unlikely to be optimal. CC: @enh-google
as i said in android's <stdbit.h>: ``` * Ideally we'd have clang builtins for all of these, like gcc has. * If/when clang catches up, we can replace all of this with direct calls to * the relevant builtins. ``` so, yeah, "please subscribe me to your newsletter" --- i'll switch android's libc over to these as soon as they're available in the platform's clang :-) see https://cs.android.com/android/platform/superproject/+/android-latest-release:bionic/libc/include/stdbit.h;l=2?q=file:stdbit.h for our current implementation, rewriting these in terms of existing builtins, which is mostly (but not always) fairly straightforward. https://github.com/llvm/llvm-project/pull/185978 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
