From: Erik S. <esc...@pe...> - 2011-12-15 19:32:09
|
The conversion intrinsics exist in LLVM, and are implemented in some of its backends. To my knowledge, currently only the ARM backend supports it, presumably via a machine instruction (or maybe via a sequence of machine instructions). Other backends will report an error when the llvm code is lowered to machine code -- that is (as I had to find out), libkernel.a will build fine on all architectures, but the respective functions cannot be used. As you say, it should not be difficult to implement this generically for all other platforms, either in pocl, or (better) in LLVM. This may be slow, but the memory savings (in particular also if this is stored in a file) may make the slow conversion worthwhile for some applications. -erik 2011/12/15 Pekka Jääskeläinen <pek...@tu...> > On 12/15/2011 09:04 PM, Erik Schnetter wrote: > >> supports the half datatype >> > > How do you think so? > http://llvm.org/docs/LangRef.**html#t_floating<http://llvm.org/docs/LangRef.html#t_floating> > > As I wrote, I think it's supported only via those two conversion > intrinsics: > > http://llvm.org/docs/LangRef.**html#int_fp16<http://llvm.org/docs/LangRef.html#int_fp16> > > My question was that who implements those intrinsics > (fp32 to fp16 to fp32) as they require some bit manipulation of > the fp fields, AFAIK (extract mantissa, exponent, sign and put > them pack to the destination) and it's unlikely the hardware has > direct instructions for such conversion. Do you mean that > the default lowering of those intrinsics produces the conversion > code too? > > Using native halfs would mean that one can use smaller adders, > multipliers, shifters etc. in the FPUs which means energy savings in > low power designs (less switching activity). Too bad it seems not to be > supported yet in LLVM, AFAIU. > > -- > --Pekka > > -- Erik Schnetter <esc...@pe...> http://www.cct.lsu.edu/~eschnett/ AIM: eschnett247, Skype: eschnett, Google Talk: sch...@gm... |