[PATCH] D38315: WIP: [ARM] Add f16 type support and code generation (part 1/2)

Oliver Stannard via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 16 08:23:14 PST 2018


olista01 added a comment.

This looks like a lot of additional complexity to deal with the case where we only have the conversion instructions, but you have made f16 a legal type.

Have you looked into the option of instead adjusting the calling convention lowering to check the original (pre-legalization) type of the argument? This would allow you to leave f16 illegal when we don't have the arithmetic instructions. There is some discussion ongoing at the moment [1] about some backends that already do something like this, and options for making that target-independent.

[1] http://lists.llvm.org/pipermail/llvm-dev/2018-January/120098.html



================
Comment at: test/CodeGen/ARM/fp16-args.ll:36
 ; HARD: vcvtb.f16.f32   [[SREG:s[0-9]+]], {{s[0-9]+}}
-; HARD-NEXT: vmov            [[REG0:r[0-9]+]], [[SREG]]
-; HARD-NEXT: uxth            [[REG1:r[0-9]+]], [[REG0]]
-; HARD-NEXT: vmov            s0, [[REG1]]
+; HARD-NEXT: vcvtb.f32.f16   [[SREG]], [[SREG]]
 
----------------
This looks like an ABI change: we previously returned an f16 value packed into the bottom half of s0, now we return an f32 value in the whole of s0.


https://reviews.llvm.org/D38315





More information about the llvm-commits mailing list