http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #23 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #18) > I think it is a bad idea to introduce the IFUNC into libgcc_s, because then > while you speed up the few users of this builtin, you slow down all users of > libgcc_s (pretty much all C++ programs and lots of C programs), because they > will need to resolve the ifunc. Do you have a pointer to some text that explains this cost? I tried to read a bit, but it seems to me that unless you use LD_BIND_NOW, the ifunc won't be resolved if it isn't called. And if it is called, the main cost compared to a normal relocation should be the feature test, which is indeed a bit long but not that bad, especially since calling popcount once increases a lot the probability that it will be called again. Not that it matters that much, interested distributions could always ship an sse4 libgcc_s where they replace the implementation of popcount, and best performance requires changing things before there is even a call to libgcc, but I'd like to understand when ifunc should be used or avoided (quite a few glibc functions seem to use ifunc, though they are much more used than popcount and most have a non-constant complexity).
