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

[Justin Holewinski]

On Mon, 2014-07-14 at 07:23 -0700, Tom Stellard wrote:
> 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.

I don't see any issues with NVPTX here.  Since we have a 'half' type in
LLVM IR, it makes sense to go ahead and use it instead of having a half
value be either 'i16' or 'half' depending on what you're trying to do
with it.

> 
> > 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev