[LLVMdev] RFC: Do we still need @llvm.convert.to.fp16 and the reverse?

[Tim Northover]

Hi all,

What do people think of doing away with the @llvm.convert.to.fp16 and
@llvm.convert.from.fp16 intrinsics, in favour of using "half" and
fpext/fptrunc? [1]

It looks like those intrinsics originally date from before "half"
actually existed in LLVM, and of course the backends have grown up
assuming that's what Clang will produce, so we'd have to improve their
support first. But the benefit would be a more uniform interface to
this type, both for front-ends and backends.

I've been poking around a bit, and as far as I can see the following
accommodations would need to be made in CodeGen:

1. Generic support to Promote f16 operations narrowed by InstCombine
back to f32.

And in Targets:

1. If there's *no* native f16 support, they can probably remain unchanged.
2. Targets with scalar f16 conversion would need it to become a legal
type (in some register class). This seems like a reasonable
requirement if there actually are instructions acting on it. But it
adds the usual overheads of supporting bitcasts and loads/stores.
3. Targets with vector f16 conversion would similarly need to legalize
the type (and in this case would probably need argument-passing
support too, since Clang forbids passing a direct __fp16 but not a
vector).

I think it would be a worthwhile change, but want to make sure backend
owners with an interest in f16 don't object to the direction. That'd
seem to be: AArch64, ARM, NVPTX, R600 and X86.

Cheers.

Tim.

[1] I think this is an orthogonal issue to whether __fp16 is a
storage-only type or actually gets native arithmetic operations: we
can still have Clang promote any value to float before actually doing
anything.