Re: [RFC] ifunc suck, use ufunc.

[OndÅej BÃlka <neleai at seznam dot cz>]

On Sun, May 24, 2015 at 10:22:50PM -0400, Rich Felker wrote:
> On Mon, May 25, 2015 at 03:43:23AM +0200, Szabolcs Nagy wrote:
> > * OndÅej BÃlka <neleai@seznam.cz> [2015-05-24 23:38:58 +0200]:
> > > A main benefit would be interlibrary constant folding. Why waste cycles
> > > on reinitializing constant, just save it to ufunc structure. Resolver 
> > > then could precompute tables to improve speed.
> > > 
> > > As interposing these you would need to interpose resolver.
> > > 
> > > An gcc support is not needed but we could get something with alternate
> > > calling convention as passing resolver struct is common and could be
> > > preserved for loops with tail calls.
> > > 
> > > A future direction could be replace plt and linker with ufunc, it would
> > > require adding function string pointer to structure and calling first
> > > generic resolver to select specific resolver.
> > > 
> > > Comments?
> > > 
> > 
> > this makes memset non-async-signal-safe. (qoi issue)
> > 
> > it is not thread-safe either and would need an acquire
> > load barrier on every invocation of memset to fix that
> > or the use of thread local storage. (conformance issue)
> > 
> > (in the example only resolve->fn is modified and idempotently,
> > this would work in practice but as soon as ->data is accessed
> > too the memory ordering guarantees are required.. which can
> > be made efficient on some archs but only in asm)
> > 
> > in the example memset is called through the wrong type
> > of function pointer: the resolver and resolvee are
> > incompatible so this is invalid c, only works in asm.
> > 
> > it is not clear to me how many such ufunc structs will be
> > in a program for a specific function and how their redundant
> > initialization is avoided.
> > (one for every call site? every tu? every dso?)
> 
> Agree with all points. IFUNC sucks, but the reasons that IFUNC sucks
> are all exacerbated by this proposal, not fixed.
> 
These were easily fixable technical details that are pointless to argue
at this stage.

A problem is that optimal function selection depends on combination of
call site, current cpy and profile feedback. If you ignore one of
parameters you would obviously get worse performance.

So make a better proposal how to handle selection acccording to this
triplet. If you cannot make one its evidence that my ufuncs are best
approach so shut up.