This is an archive of the discontinued LLVM Phabricator instance.

[ARM] add .f16 -> .16 token alias

Authored by ychen on Sep 21 2020, 6:30 PM.



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?

Diff Detail

Event Timeline

ychen created this revision.Sep 21 2020, 6:30 PM
ychen requested review of this revision.Sep 21 2020, 6:30 PM

Hello. Can you add some tests? Perhaps something to places like neon-vst-encoding.s/neon-vld-encoding.s

Is this right?

GCC does this, so it seems like a fine idea to me.

ychen retitled this revision from [ARM] add .f16 -> .f16 token alias to [ARM] add .f16 -> .16 token alias.Sep 22 2020, 1:21 PM
ychen added a comment.Sep 24 2020, 9:48 PM

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?

ychen added a comment.Sep 25 2020, 8:44 AM

Is this to ease porting between gcc and clang?

Yeah, sort of. There are not many uses of vst1.f16, so I could replace them with vst1.16 in the source code directly.

ychen abandoned this revision.Nov 10 2020, 10:20 AM

Abandoning. It doesn't feel like a trivial fix and I could workaround this offline.