search for: cl_khr_fp16

...eof(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 "...

...eof(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 "...

...f(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 j...

...loating-point type, which in particular is used in OpenCL C. Please review. Background and motivation. Whilst the half type is defined by IEEE 754-2008 as storage only (i.e. no arithmetic is supposed to be performed on values of this type), it's growing in importance in embedded systems. The cl_khr_fp16 extension of OpenCL lifts restrictions for declaring half variables and arrays, dereferencing half pointers, performing arithmetic and conversions, etc. The latest version of the C++ ABI supports half as well. Therefore, we believe half should become a fundamental type in LLVM. (After all, LLVM a...

...in particular is used in OpenCL C. > Please review. > > Background and motivation. Whilst the half type is defined by IEEE 754-2008 > as storage only (i.e. no arithmetic is supposed to be performed on values of > this type), it's growing in importance in embedded systems. The cl_khr_fp16 > extension of OpenCL lifts restrictions for declaring half variables and > arrays, dereferencing half pointers, performing arithmetic and conversions, > etc. The latest version of the C++ ABI supports half as well. Therefore, > we believe half should become a fundamental type in LLVM...

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