Maybe we should get rid of ifuncs

[Zack Weinberg]

On Tue Apr 23, 2024 at 9:41 PM EDT, Richard Henderson wrote:
> On 4/23/24 11:14, Zack Weinberg wrote:
> > (2) Are there existing ifuncs that perform CPU-capability-based
> > function selection that*could not*  be replaced with an array of bit
> > vectors like what I sketched in the previous paragraph?
>
> How much is in actual use, I have no idea.  However:
> Even x86 cpuid generates a staggeringly large bit vector.

Oof, yeah.  sizeof(struct cpu_features) == 488 on x86_64, and over
half of that is cpuid dumps.  It probably _could_ be compacted,
but as Florian pointed out any compaction we implement means glibc
has to be updated for new CPU features (but then again we have to
do that _anyway_...)

Another thing that looking at cpu_features makes obvious is that
several architectures include numbers that can't easily be reduced
to one-hot representation.  It'd be reasonable to want to dispatch on
cache line size, for instance.  I don't like the idea of embedding
something even vaguely resembling a bytecode interpreter in ld.so,
and yet...

I'm very curious what the plan for function multiversioning in GCC
and LLVM is, and how close to declarative it gets.

zw