http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Marc Glisse from comment #23) > (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). If you use prelink, then everything successfully prelinked is LD_BIND_NOW too (for most relocations without runtime cost, but for ifunc not), and for every IFUNC that requires a .gnu.conflict ifunc relocation that needs to be resolved right away.
