Why doesn't /proc/cpuinfo contain fp16 if FEAT_FP16 is supported?

Question

I know that in my ARM FEAT_FP16 is supported.

I expect seeing fp16 in the list of features reported by cat /proc/cpuinfo:

$ cat /proc/cpuinfo | grep fp | sort -u
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma dcpop asimddp asimdfhm

Here we see that fp16 is not present in this list. Why?

Crawfish

I believe it should be 'fphp' and not 'fp16', if it is working. In order to set this, the configuration options 'VFPv3' needs to be active. The code looks at the MVFR1 to determine if the features is present. In order to get 'VFPv3', we need CPUv7 and VFP defined. git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/… – Hartebeest

It looks like it is only using CPU_V7 and not CPU_V7M. What is the actual model of CPU you have? Although, if you are using Ubuntu, it should have many CPUs configured (to be handled by the kernel; only one is active at a time), so the option should be active. Err, indeed it is in the line 'fphp', just after atomics. – Hartebeest

@artlessnoise Indeed, it seems that it is named fphp rather than fp16. Why ideas why? – Crawfish

Because, it is half precision floating point, which takes 16 bits of data. The others are referred to as 'double precision' and 'single precision', not fp64 and fp32. A question could be why use fp16? Feel free to self answer. – Hartebeest

I put back the arm and half-precision-float tags which are perfectly reasonable for this question. It's just that linux needed to be added. – Chilung

@artlessnoise Re: "why use fp16?: because ARM reference manual uses fp16. However, I understand that cpuinfo is not (?) required to use feature names from the manual. – Crawfish

Yes, the IEEE standards (and compiler people) will use the term 'half-precision'. en.wikipedia.org/wiki/Half-precision_floating-point_format Some one would be upset if they choose fp16. I think fphp is a lesser evil. but would any choice be correct to everyone? Again, you can self answer this question so that other people will not be confuse. I empathize, but I don't think it was a mistake to use fphp. – Hartebeest

Also, stackoverflow.com/tags/half-precision-float/synonyms is interesting. Imagine a world where languages were not context sensitive nor ambiguous. Gotta go code :) – Hartebeest

FPHP is the name of the field in the feature register, so it's a reasonable choice. ARM now uses FP16 as the official mnemonic for the feature, but that naming scheme was a later addition to the spec. The first version of the ARMv8-A spec (A.a) describes 16-bit floating point support, and uses FPHP for the corresponding bitfield, but doesn't contain the string FP16 anywhere. I couldn't find the first commit of the Linux code, but it may well predate ARM's FP16 nomenclature. – Chilung

@NateEldredge Thanks! I've informed user solidpixel. – Crawfish

@NateEldredge A simple question: does the fphp (reported by cat /proc/cpuinfo) indicate "support for fp16 conversions and fp16 data processing" OR "support for fp16 conversions" only? Have a look at solidpixel's comment. – Crawfish

@pmor: A few lines below the code linked by artless noise, you can see that the FPHP flag in the kernel is set if the value in the corresponding field of MVFR1 is 0x3, indicating full fp16 support including data processing instructions. The conversion instructions (e.g. fcvt h0, d1) are part of base ARMv8-A, not associated with any particular FEATure, and should be supported by every machine that has any floating point support at all. – Chilung