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

[Tom Stellard]

On Mon, Jul 14, 2014 at 01:08:54PM +0100, Tim Northover wrote:
> 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]
> 

I am in favor of using fpext/fptrunc instead of the intrinsics.

> 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.
> 

Are there any in-tree targets that natively support fp16 operations?

-Tom

> 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.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev