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

[Matt Arsenault]

On 07/15/2014 06:23 AM, Tim Northover wrote:
>>> 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.
No, I never committed that

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