[LLVMdev] [PATCH] OpenCL half support

[Zhang, Chihong]

Sorry. I should have clearly said: "there are already quite some embedded/mobile chips providing fp16 ALU operations for performance".

Thanks,
Chihong

-----Original Message-----
From: Chris Lattner [mailto:clattner at apple.com] 
Sent: Monday, March 21, 2011 5:05 PM
To: Zhang, Chihong
Cc: Anton.Lokhmotov at arm.com; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] [PATCH] OpenCL half support


On Mar 21, 2011, at 1:59 PM, Zhang, Chihong wrote:

> 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.

As I've said several times now :), I'm ok with having fp16 as a native LLVM type so long as there is hardware that implements fp16 arithmetic operations like add and sub with correct fp16 rounding etc.

-Chris

> 
> 
> -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