Otherise asm instrutions like "vst1.f16" are not parsable.
I'm not sure if 2cf294a213c01d074c35f1a6d579092da8caa54c should have include
this or not and googling for the table number does not reveal anything for me.
Is this right?
This patch caused some failures (fullfp16-neg.s etc.) and seems changed the behavior of parsing "vmov.f16 s1,r2" for -fp16 from fail to pass. With this patch and -fp16, "vmov.f16 s1,r2" would be parsed to "vmov.16 s1,r2" which is defined to alias "vmov s1,r2".
2cf294a213c01d074c35f1a6d579092da8caa54c implemented "Data type specification flexibility" (in ArmV8-A manual, paragraph F2.9.5, Table F2-9) except f16, so adding .f16 to .16 case here should be doing the right thing. IIUC "Data type specification flexibility" should be restricted to <dt> field which 2cf294a213c01d074c35f1a6d579092da8caa54c did not implement (judging from the failures caused by this patch). It has been almost 11 years, so I guess the feature is not widely used. If I'm going to make TokenAlias restricted to <dt> field as the manual says, "vst1.f16" is still not parsable beause it does not use <dt> field.
"vst1.f16" -> "vst1.16" seems be a GCC extension. GNU as docs does not mention these. It is hard to implement this GCC-compatible function without looking into GNU as source code.
2cf294a213c01d074c35f1a6d579092da8caa54c possibly pre-dates when fp16 was a common thing in the ARM backend.
vmov.16 r3, s6 (or vmov.p8 r5, s2) seems like an odd instruction to me if they are aliases of vmov, but we are reaching the limit of my very narrow assembler knowledge. It seems that gcc will treat vmov.16 as a vmov.f16 (and require fullfp16). It will not accept vmov.p8, but other assemblers will and treat them like a vmov.
Is this to ease porting between gcc and clang?