Re: [RFC] ifunc suck, use ufunc.

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

On Mon, May 25, 2015 at 01:17:47PM +0800, Andrew Pinski wrote:
> On Mon, May 25, 2015 at 12:40 PM, OndÅej BÃlka <neleai@seznam.cz> wrote:
> > 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.
> 
> Since when is glibc x64 specific :).  There are other targets which
> use ifuncs and that is what he is talking about.
>

Its example where ufunc would be useful. We also newer used ifunc for
cross-platform selection its just always used for some specific
architecture.

So now we should focus on making them usable for x64. After that we
could port these to other architectures. As I said before its too early for
implementation details. Adding these now would result on rewriting them
five times until interface stabilizes and abi could change.