[Bug 278417] The _cvtsh_ss() intrinsic function generates illegal instructions
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278417
--- Comment #7 from Dimitry Andric ---
(In reply to Yuri Victorovich from comment #5)
Ideally the program should disable the parts that require f16c, but if that is
not possible, you could mark the port as requiring a CPU that supports the
feature.
However, to be able to do so, support for f16c should be added to bsd.cpu.mk.
Then you could check it in the port with something like:
if defined(MACHINE_CPU) && ${MACHINE_CPU:Mf16c}
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 278417] The _cvtsh_ss() intrinsic function generates illegal instructions
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278417 --- Comment #6 from Dimitry Andric --- FWIW, clang defines __F16C__ for the following -march= settings: alderlake, arrowlake, arrowlake-s, bdver2, bdver3, bdver4, broadwell, btver2, cannonlake, cascadelake, clearwaterforest, cooperlake, core-avx-i, core-avx2, emeraldrapids, gracemont, grandridge, graniterapids, graniterapids-d, haswell, icelake-client, icelake-server, ivybridge, knl, knm, lunarlake, meteorlake, pantherlake, raptorlake, rocketlake, sapphirerapids, sierraforest, skx, skylake, skylake-avx512, tigerlake, x86-64-v3, x86-64-v4, znver1, znver2, znver3, znver4. I'm unsure if these names correspond exactly to what is in bsd.cpu.mk now. Also, I don't see much use of the bsd.cpu.mk features in the src tree, but maybe it is used more often in the ports tree? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278417] The _cvtsh_ss() intrinsic function generates illegal instructions
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278417 --- Comment #5 from Yuri Victorovich --- (In reply to Dimitry Andric from comment #4) I am not sure what should happen when some project is just using the F16C extension. According to the rules, the default port/package build should support the basic amd64 CPU with SSE2. But this software can't even work on such CPU. And Clang doesn't provide the default implementation. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278417] The _cvtsh_ss() intrinsic function generates illegal instructions
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278417 --- Comment #4 from Dimitry Andric --- (In reply to Yuri Victorovich from comment #2) > But this should be covered by the CPUTYPE setting. That seems to be unimplemented at this point. The llvm getHostCPUFeatures() function has support for detecting the feature from CPUID bits, but it looks like that is only used for e.g. -march=native. I don't maintain share/mk/bsd.cpu.mk, but it seems logical to have some support added there? > clang should know that this CPU doesn't support such instructions and should > emit a generic replacement. There is a note in f16cintrin.h about this: /* NOTE: Intel documents the 128-bit versions of these as being in emmintrin.h, * but that's because icc can emulate these without f16c using a library call. * Since we don't do that let's leave these in f16cintrin.h. */ so apparently it is not implemented. I guess you simply have to avoid relying on these intrinsics if your CPU does not support them. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278417] The _cvtsh_ss() intrinsic function generates illegal instructions
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278417 --- Comment #3 from Dimitry Andric --- Indeed, this intrinsic is defined in f16cintrin.h, but that header is only included by immintrin.h if __F16C__ is defined, and that macro is normally only available when the CPU features support F16C. If you force the support by adding -mf16c on the command line, you have to make sure your CPU actually has this instruction, or have some other mechanism to ensure that the function is never called unless the feature is detected at run-time. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278417] The _cvtsh_ss() intrinsic function generates illegal instructions
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278417 --- Comment #2 from Yuri Victorovich --- (In reply to Mark Millard from comment #1) > Is your hardware missing the F16C instruction set extension? No, it's not supported on my system. But this should be covered by the CPUTYPE setting. clang should know that this CPU doesn't support such instructions and should emit a generic replacement. Different CPUTYPEs introduce different extensions like this. It looks like clang misses this one. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278417] The _cvtsh_ss() intrinsic function generates illegal instructions
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278417 Mark Millard changed: What|Removed |Added CC||marklmi26-f...@yahoo.com --- Comment #1 from Mark Millard --- For reference: static __inline float __DEFAULT_FN_ATTRS128 _cvtsh_ss (unsigned short __a) Converts a 16-bit half-precision float value into a 32-bit float value. Quoting https://en.wikipedia.org/wiki/Half-precision_floating-point_format : Support for half precision in the x86 instruction set is specified in the F16C instruction set extension, first introduced in 2009 by AMD and fairly broadly adopted by AMD and Intel CPUs by 2012. This was further extended up the AVX-512_FP16 instruction set extension implemented in the Intel Sapphire Rapids processor. Quoting https://en.wikipedia.org/wiki/F16C : The F16C[1] (previously/informally known as CVT16) instruction set is an x86 instruction set architecture extension which provides support for converting between half-precision and standard IEEE single-precision floating-point formats. Is your hardware missing the F16C instruction set extension? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278417] The _cvtsh_ss() intrinsic function generates illegal instructions
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278417 Yuri Victorovich changed: What|Removed |Added Assignee|b...@freebsd.org|toolchain@FreeBSD.org CC||d...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
