> > I am worried about scenario where ifunc selector calls function foo > > defined locally and foo is also used from other places possibly in hot > > loops. > > > > > > > So it is not really reliable fix (though I guess it will work a lot of > > > > common code). I wonder what would be alternatives. In GCC generated > > > > profling code we use TLS only for undirect call profiling (so there is > > > > no need to turn off rest of profiling). I wonder if there is any chance > > > > to not make it seffault when it is done before TLS is set up? > > > > > > IFUNC selector should make minimum external calls, none is preferred. > > > > Edge porfiling only inserts (atomic) 64bit increments of counters. > > If target supports these operations inline, no external calls will be > > done. > > > > Indirect call profiling inserts the problematic TLS variable (to track > > caller-callee pairs). Value profiling also inserts various additional > > external calls to counters. > > > > I am perfectly fine with disabling instrumentation for ifunc selectors > > and functions only reachable from them, but I am worried about calles > > used also from non-ifunc path. > > Programmers need to understand not to do it.
It would help to have this documented. Should we warn when ifunc resolver calls external function, comdat of function reachable from non-ifunc code? > > > For example selector implemented in C++ may do some string handling to > > match CPU name and propagation will disable profiling for std::string > > On x86, they should use CPUID, not string functions. > > > member functions (which may not be effective if comdat section is > > prevailed from other translation unit). > > String functions may lead to external function calls which is dangerous. > > > > Any external calls may lead to issues at run-time. It is a very bad idea > > > to profile IFUNC selector via external function call. > > > > Looking at https://sourceware.org/glibc/wiki/GNU_IFUNC > > there are other limitations on ifunc except for profiling, such as > > -fstack-protector-all. So perhaps your propagation can be used to > > disable those features as well. > > So, it may not be tree-profile specific. Where should these 2 bits > be added? If we want to disable other transforms too, then I think having a bit in cgraph_node for reachability from ifunc resolver makes sense. I would still do the cycle detection using on-side hash_map to avoid polution of the global datastructure. Thanks, Honza > > > "Unfortunately there are actually a lot of restrictions placed on IFUNC > > usage which aren't entirely clear and the documentation needs to be > > updated." makes me wonder what other transformations are potentially > > dangerous. > > > > Honza > > > -- > H.J.
