Bugzilla Automation <bugzi...@freebsd.org> has asked freebsd-gecko (Nobody)
<ge...@freebsd.org> for maintainer-feedback:
Bug 281179: devel/llvm1[789] removal of arm_bf16.h from _BE_INCS_ARM in
Makefile's was incorrect
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281179
--- Description ---
For devel/llvm1[789]:
clang/lib/Basic/Targets/ARM.cpp has:
if (HasBFloat16) {
Builder.defineMacro("__ARM_FEATURE_BF16", "1");
Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1");
Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1");
}
(The above is because target ARM in llvm covers AArch32, even for armv8.)
clang/lib/Basic/Targets/AArch64.cpp has:
if (HasBFloat16) {
Builder.defineMacro("__ARM_FEATURE_BF16", "1");
Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1");
Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1");
}
(The above is because target AArch64 in llvm covers only AArch64, not AARch32.)
The above suggests bf16 support has 32-bit support (even if it is armv8
32-bit). Looking for AArch32 state in:
DDI0487K_a_a-profile_architecture_reference_manual.pdf
it says (via the AArch32 column of a table):
BF16 Supported if FEAT_AA32BF16 is implemented.
So the documentation agrees about there being AARch32 support
possible. (There is also AArch64 support possible.)
Also: I've tested that putting arm_bf16.h back in the llvm18
Makefile to allow part of a poudriere-devel based armv7 www/firefox
build attempt to work instead of getting an error about an
include referencing <arm_bf16.h> not finding the file. So the
deletion lead to part of a port/package build being broken. (The
port has more broken than just that.)
For reference the tested change was:
-_BE_INCS_ARM= arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sme.h \
+_BE_INCS_ARM= arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h
arm_sme.h \
(My Makefile has other personal differences from the official
Makefile as well.)
