From: Carlos S. de La L. <car...@ur...> - 2011-12-16 15:43:09
|
Yep, the item is stored in fp16 format inside the i16 of course... I thought it would work as you can have a target independent f16 to f32 conversion but that requires assuming the storage format is IEEE FP. Anyways, pocl-wide it is enough as it is now IMHO, if LLVM supports codegen for halfs in a target then the kernel library uses it, otherwise it does not. Carlos On Fri, 2011-12-16 at 10:18 -0500, Erik Schnetter wrote: > On Fri, Dec 16, 2011 at 7:03 AM, Carlos Sánchez de La Lama > <car...@ur...> wrote: > 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). > > > The intrinsics do not work -- tried 3.0 and trunk. By looking at the > code, I believe that this conversion intrinsic is only defined for > ARM. > > > The i16 contains a bit pattern representing the fp16 value, it cannot > be interpreted as integer value. It seems to me that using i16 is > purely a hack to avoid introducing a new (and very limited) LLVM > datatype, because by using an i16 one ensures that load/store etc. > work correctly. > > > -erik > > > -- > Erik Schnetter <esc...@pe...> > http://www.cct.lsu.edu/~eschnett/ > AIM: eschnett247, Skype: eschnett, Google Talk: sch...@gm... |