search for: fp_to_fp16

...ould again interpret the higher 16 bits in 32-bit registers and that would be wrong. Instead of trying to undo this early legalization/combining, I found this approach easier and cleaner. - As a consequence, the isel dags are in a more 'normal form'. I.e. it relies less on funny nodes FP_TO_FP16 and FP16_TO_FP, which are funny because they perform float up/down converts and produce i32 values by moving from/to integer and float registers. Instead, FP_EXTEND and FP_ROUND nodes will be introduced, so this is more a clean up rather than e.g. addressing a correctness issue. Unfortunatl...

...y the place where the 16-bit size is needed to make the operation possible. Basically what we have is a very similar implementation to promoting integers, but that doesn't work for FP because we lose out on intermediate rounding. It seems like what we should instead do is insert fp16_to_fp and fp_to_fp16 in the libcall and arithmetic op handling. And use i16 to connect the legalized pieces together. Similar to how we use integer types when softening operations. I'm not sure if there would still be rounding issues with this, but it seems closer to matching the IR. Unfortunately, I think this wo...

...eded to make > the operation possible. Basically what we have is a very similar > implementation to promoting integers, but that doesn't work for FP because > we lose out on intermediate rounding. > > > > It seems like what we should instead do is insert fp16_to_fp and > fp_to_fp16 in the libcall and arithmetic op handling. And use i16 to > connect the legalized pieces together. Similar to how we use integer types > when softening operations. I'm not sure if there would still be rounding > issues with this, but it seems closer to matching the IR. > > > &...

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd. >On 12/4/2017 6:44 AM, Sjoerd Meijer via llvm-dev wrote: >&...

Hi all, -soft-float can not be rightly use by llc. All float function operation will call soft float, but not hard. My mips device cannot support half float type, so I hack the llvm, and add soft half float and add -soft-float option. I add the function define for __gnu_f2h_ieee() and __gnu_h2f_ieee (), and it can call the soft half float. However, all the others function about

...t: 06 December 2017 08:32 To: Friedman, Eli; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [RFC] Half-Precision Support in the Arm Backends Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd. >On 12/4/2017 6:44 AM, Sjoerd Meijer via llvm-dev wrote: >&...

...t: 06 December 2017 08:32 To: Friedman, Eli; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [RFC] Half-Precision Support in the Arm Backends Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd. >On 12/4/2017 6:44 AM, Sjoerd Meijer via llvm-dev wrote: >&...