From: Carlos S. de La L. <car...@ur...> - 2011-12-16 11:59:57
|
Just for clarification: There is no fp16 type in LLVM, at all, neither for computation nor storage. It is not defined in LLVM assembly language. What clang does is generates i16 (integer) values for halfs, and converts i16 to floats before operating with them. The LLVM intrinsics convert i16 <-> float, there is no fp16 type. I would expect therefore those intrinsics to work on all the LLVM codegen targets (int to float works, so this should also). >From the pocl kernel library I think the current way is correct, if halfs are not mandatory in OpenCL, check for the "half" support in the compiler and activate the extension if it is there. Support meaning not only that the compiler "eats" the keyword but also its size as the standard defines it. So, as it is done. To map halfs to real half-operating-hardware LLVM-side changes would be needed, to add the half as a real type, as right now it is not possible (without a lot of def-use chain analysis) to determine whether a float comes from a "half/i16" or is a real float. BR Carlos On Thu, 2011-12-15 at 14:32 -0500, Erik Schnetter wrote: > 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 > > As I wrote, I think it's supported only via those two > conversion > intrinsics: > > 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... > ------------------------------------------------------------------------------ > 10 Tips for Better Server Consolidation > Server virtualization is being driven by many needs. > But none more important than the need to reduce IT complexity > while improving strategic productivity. Learn More! > http://www.accelacomm.com/jaw/sdnl/114/51507609/ > _______________________________________________ Pocl-devel mailing list Poc...@li... https://lists.sourceforge.net/lists/listinfo/pocl-devel |