[LLVMdev] [PATCH] OpenCL half support

[Villmow, Micah]

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Chris Lattner
> Sent: Friday, March 18, 2011 1:15 PM
> To: Anton.Lokhmotov at arm.com
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] [PATCH] OpenCL half support
> 
> 
> On Mar 17, 2011, at 10:17 AM, Anton Lokhmotov wrote:
> 
> > Hi Chris,
> >
> > So what do you think about this proposal?  If you agree, it would be
> good to
> > include the patch into the 2.9 release (to avoid breaking
> compatibility
> > later).
> 
> Hi Anton, I'm sorry I don't have the patch anymore.  Please resend.  It
> is too late for new features in 2.9 though.
> 
> >> The last paragraph in section 9.6 says: "NOTE: Implementations may
> >> perform floating-point operations on half scalar or vector data
> types
> >> by converting the half values to single precision floating-point
> values
> >> and performing the operation in single precision floating-point. In
> >> this case, the implementation will use the half scalar or vector
> data
> >> type as a storage only format."
> 
> Ok.
> 
> >> That is, an implementation may perform operations on half scalar and
> >> vector values either using half-precision operations (if supported
> >> natively) or using single-precision operations (always supported
> >> natively).  In either case, it's desirable to represent half
> operations
> >> in the IR, and let the backend make the decision.
> 
> It doesn't impact the utility of your approach, but I could not
> disagree more here.  It would be *absolutely* the wrong thing to do for
> backends to compile IR half float operations into full float
> operations.  Doing this would cause all sorts of problems with constant
> folding being inconsistent etc.
> 
> Adding half float to LLVM IR is *only* reasonable if you have hardware
> that supports half float, or if you want to add softfloat operations
> for these.  If we have a fp16 datatype in the IR, code generation
> *must* codegen these to something that implements the correct fp16
> semantics.
> 
> C is not a portable language, and trying to make LLVM IR magically fix
> this is a bad approach.  Just like C compilers need to know
> sizeof(long), sizeof(void*) and many many other target specific
> details, an OpenCL compiler would need to know whether to generate fp16
> or not.
[Villmow, Micah] Chris, In OpenCL, the user has to explicitly state that they want to use fp16 and it is illegal to use the half data type for computation if it isn't natively supported. I think it would be useful to have fp16 in the IR for the reason that we support load/stores of the data type, but not operations on the data type. Right now we handle that by treating them like 16bit ints, but it would be nice to be able to represent them correctly.
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev