Misc. bug: HWCAP2_I8MM defined as 0 instead of real value (1 << 13)

[TianyuLi0]

Name and Version

build: 3983 (8841ce3)

Introduced via #9684

Operating systems

No response

Which llama.cpp modules do you know to be affected?

No response

Problem description & steps to reproduce

On Arm CPU with i8mm feature platform.

In ggml.c

default HWCAP2_I8MM as default 0 should be improved.

#if !defined(HWCAP2_I8MM)
#define HWCAP2_I8MM 0
#endif

HWCAP2_I8MM should be defined at following value instead,
#define HWCAP2_I8MM (1 << 13)
Refer to https://github.com/torvalds/linux/blob/master/arch/arm64/include/uapi/asm/hwcap.h#L76C1-L76C31

This lead to ggml_arm_arch_features.has_i8mm initialized as 0 instead of 1 when i8mm present in lscpu's output.

First Bad Commit

No response

Relevant log output

No response

[slaren]

I wonder if the intent here was to disable I8MM in this case, since if HWCAP2_I8MM is not already defined it may be because the version of linux being built on is too old. Not sure if I8MM requires OS support, but I imagine it does if it adds new registers. Did you verify that setting it to the correct value fixes your problem?

[TianyuLi0]

I wonder if the intent here was to disable I8MM in this case, since if HWCAP2_I8MM is not already defined it may be because the version of linux being built on is too old. Not sure if I8MM requires OS support, but I imagine it does if it adds new registers. Did you verify that setting it to the correct value fixes your problem?

Yes, the correct value fixes my problem. gemv/gemm go to the optimized kernel instead of the slow reference implementation.

In my case (ubuntu 20.04) the kernel support is there(lspcu shows i8mm) but glibc header asm/hwcap.h is old and HWCAP2_I8MM is not defined.