On Thu, Feb 29, 2024 at 7:11 AM H.J. Lu <hjl.to...@gmail.com> wrote: > > On Thu, Feb 29, 2024 at 7:06 AM Jan Hubicka <hubi...@ucw.cz> wrote: > > > > > > 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? > > That will be nice. > > > > > > > > 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. > > > > I will see what I can do. > >
The v2 patch is at https://patchwork.sourceware.org/project/gcc/list/?series=31627 -- H.J.
