Re: Maybe we should get rid of ifuncs

[enh <enh@google.com>]

On Wed, Apr 24, 2024 at 7:43 AM Zack Weinberg <zack@owlfolio.org> wrote:
>
> 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.

https://github.com/ARM-software/acle/blob/main/main/acle.md#function-multi-versioning
is the arm64 spec. the generated code is basically an ifunc resolver
that does "if ((hwcap & ... ) && (hwcap2 & ...))".

you can see the basic idea in https://reviews.llvm.org/D155026.

> zw