From: Pekka J. <pek...@tu...> - 2011-12-20 08:41:32
|
For the record, LLVM now has half support in the IR too: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111219/133712.html On 12/16/2011 05:46 PM, Carlos Sánchez de La Lama wrote: > 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... > > -- --PJ |