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

[Tim Northover]

> > I am in favor of using fpext/fptrunc instead of the intrinsics.
>
> The problem with this is the half type assumes you have half registers. I
> came up with some ugly hack that involved forcing custom lowering to make
> half loads/stores work for R600, but it was much easier to handle the
> intrinsic.

Is that the code in performStoreCombine? It looks unrelated, so
possibly not, but it was the closest I could find in R600.

Anyway, I can see that there could well be targets that have
conversion operations available but don't want to mark f16 as a legal
type for whatever reason. I think using i16 globally is a hack to
achieve that, though.

I think the best approach would be to let generic softening code
handle it during type legalization (after some poking around, I think
part of your load/store problem was because f16 isn't marked for
promotion or softening in computeRegisterProperties even when there's
no register class around).

As a half-way house, the fptrunc/fpext operations could be softened to
the already existing FP16_FROM_FP32/FP16_TO_FP32 ISD nodes, and then
lowered to libcalls if even those operations aren't available.

The main difficulty is going to be preventing non-storage operations
from creeping in. InstCombine is already capable of forming them from
fptrunc/fadd/fpext and so on. That suggests we might want the default
handling to be something between Promote and Soften; or to disable
that InstCombine.

Cheers.

Tim.