Re: Model specific optimizations?

[Szabolcs Nagy <nsz@port70.net>]

* Markus Wichmann <nullplan@gmx.net> [2016-09-29 16:21:26 +0200]:
> I wanted to ask if there is any wish for the near future to support
> model-specific optimizations. What I mean by that is multiple
> implementations of the same function, where the best implementation is
> decided at run-time.

musl already does some runtime selection based on hw/kernel
features (arm atomics, vdso).

it could use similar approaches for micro-architecture specific
optimizations.

this has a maintenance cost (hard to test, hard to benchmark),
code size cost (all variants has to be present at runtime)
and dispatch cost (it has to happen at startup or lazily) these
costs are rarely justified.

(there are secondary effects: glibc dispatches memcpy at runtime
so the compilers have a hard time deciding when to inline it,
as a consequence sometimes -O0 gives better performance than -O3
on x86 with glibc.)

> One simple example would be PowerPC's fsqrt instruction. The PowerPC
> Book 1 defines it as optional and provides no way to know specifically,
> if the currently running processor supports this instruction besides
> executing it and seeing if you get a SIGILL.

if there is no linux hwcap bit for this then we cant do much about it.

runtime dispatch only works if there is a reasonable way to detect
hw features (hwcap, cpuid instruction, vdso something) e.g. parsing
/proc/cpuinfo to figure out the cpu and guessing features from that
or registering sigill signal handlers are not ok.

> Then organization: Are we going the glibc route, which gathers all
> indirect functions in a single section and initializes all of the
> pointers at startup (__libc_init_main()), or do we put these checks
> separately in each function?

glibc uses ifunc for this, musl does not support ifunc at this point.