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

[Anton Korobeynikov]

Historically the only reason for these intrinsics was the lack of
native support for f16 on any target. On ARM f16 was storage only, so
stuff was promoted to / from float at every operation.

Looks like we need to be very careful here and not to change
storage-only semantics. Besides this I'm ok with dropping them.

On Mon, Jul 14, 2014 at 4:08 PM, Tim Northover <t.p.northover at gmail.com> 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]
>
> 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.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University