[LLVMdev] [PATCH] OpenCL half support

[Zhang, Chihong]

Hi Chris,

It is important for embedded/mobile computation to have efficient fp16 support, otherwise those users will suffer from the merging problem with their local LLVM with native fp16 type they add (locally). So we should either add full fp16 support as a basic floating point type or enhance the LLVM infrastructure to make floating point type as scalable as int type.


-Chihong

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner
Sent: Monday, March 21, 2011 11:26 AM
To: Anton.Lokhmotov at arm.com
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] [PATCH] OpenCL half support


On Mar 21, 2011, at 3:44 AM, Anton Lokhmotov wrote:

>> 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.
> Yes, our graphics hardware natively supports some fp16 arithmetic
> operations.

Ok.

>> 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.
> Yes, it's just another example of LLVM-IR non-portability.  Basically, any
> fp16 arithmetic code can be generated only if the cl_khr_fp16 extension is
> supported (otherwise, the frontend would reject even declaring fp16
> variables, leave alone performing arithmetic on them).

If the backend generates softfloat (or some other expansion) for fp16, then a native fp16 type would be perfectly portable.  This is just not the "portability" that you're looking for (which is not behavior preserving, so it isn't portability by its standard definition).

-Chris
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev