[RFC] ifunc suck, use ufunc.

[Ondřej Bílka]

On Sun, May 24, 2015 at 11:15:10PM -0400, Rich Felker wrote:
> On Mon, May 25, 2015 at 04:36:52AM +0200, Ondřej Bílka 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)
> > >
> > Did I explicitly say that its architecture specific optimization or did
> > I forgot?
> 
> AS-safety is broken regardless of arch. Only the barrier stuff if
> arch-specific.
> 
> > > 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.
> > > 
> > Thats why I intended it as architecture-specific. On x64 it will work
> > along with memset prototype. Adding atomic/locking in resolver would be unnecessary
> > overhead.
> > 
> > Could make this generic by defining macros that expand to atomic read on
> > archs that don't act as pram.
> 
> Do you realize the relative cost of an atomic read (barrier) versus a
> small memset? This is like driving an extra mile to a cheaper gas
> station to save $0.01 per gallon...
>
Since when does atomic read for x64 generates barrier?
And you don't need to establish any happens-before relashionship here,
so relaxed atomic read suffices. With atomic write you could only call a
function and you are ok or resolver multiple times. A resolver would
already take lock so its handled.

A problem is only for arch that don't do atomic write of pointers. Chips
that do this are typically so slow that if you care about performance
best you could do is sell it and buy something decent. Nobody would try
to improve performance by making several variants.