[LLVMdev] [PATCH] OpenCL half support

Chris Lattner clattner at apple.com
Fri Mar 18 13:14:38 PDT 2011


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.

-Chris



More information about the llvm-dev mailing list