[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