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
> -----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
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Villmow, Micah wrote:
<blockquote
cite="mid:D556DCBBC0EA924A9AC80003B62121120600E507D8@sausexmbp02.amd.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated"
href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a>
[<a class="moz-txt-link-freetext"
href="mailto:llvmdev-bounces@cs.uiuc.edu">mailto:llvmdev-bounces@cs.uiuc.edu</a>]
On Behalf Of Chris Lattner
Sent: Friday, March 18, 2011 1:15 PM
To: <a class="moz-txt-link-abbreviated"
href="mailto:Anton.Lokhmotov@arm.com">Anton.Lokhmotov@arm.com</a>
Cc: <a class="moz-txt-link-abbreviated"
href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>
Subject: Re: [LLVMdev] [PATCH] OpenCL half support
On Mar 17, 2011, at 10:17 AM, Anton Lokhmotov wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Chris,
So what do you think about this proposal? If you agree, it would be
</pre>
</blockquote>
<pre wrap="">good to
</pre>
<blockquote type="cite">
<pre wrap="">include the patch into the 2.9 release (to
avoid breaking
</pre>
</blockquote>
<pre wrap="">compatibility
</pre>
<blockquote type="cite">
<pre wrap="">later).
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The last paragraph in section 9.6 says:
"NOTE: Implementations may
perform floating-point operations on half scalar or vector data
</pre>
</blockquote>
</blockquote>
<pre wrap="">types
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">by converting the half values to single
precision floating-point
</pre>
</blockquote>
</blockquote>
<pre wrap="">values
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">and performing the operation in single
precision floating-point. In
this case, the implementation will use the half scalar or vector
</pre>
</blockquote>
</blockquote>
<pre wrap="">data
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">type as a storage only format."
</pre>
</blockquote>
</blockquote>
<pre wrap="">Ok.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap="">operations
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">in the IR, and let the backend make the
decision.
</pre>
</blockquote>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->[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.
</pre>
</blockquote>
Maybe worth pointing out that there are architectures that natively
support 16bit floating point in llvm. PTX, the new backend of which has
just been added to 2.9 can handle fp16 -> fp32 conversion in
hardware. I agree we should have support for fp16 in the IR, it's
fiddly trying to make do without this and gets used frequently in
simulations and graphics in particular.<br>
<br>
<blockquote
cite="mid:D556DCBBC0EA924A9AC80003B62121120600E507D8@sausexmbp02.amd.com"
type="cite">
<blockquote type="cite">
<pre wrap="">-Chris
_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext"
href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext"
href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
</body>
</html>
> 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.> 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). Anton.
Chris Lattner wrote:> I'm sorry I don't have the patch anymore. Please resend.Attached. (Copying to cfe-dev, as the patch is dual Clang/LLVM.) Anton Korobeynikov wrote:> PS: my 2 cents: do not forget to handle the existing half fp <-> float > conversion intrinsics.We are not quite sure what to do with them. Can anyone help? Best wishes, Anton. -------------- next part -------------- A non-text attachment was scrubbed... Name: 00004-half-llvm.patch Type: application/octet-stream Size: 11978 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110322/f3d5813b/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 00004-half-clang.patch Type: application/octet-stream Size: 24682 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110322/f3d5813b/attachment-0001.obj>
Any comments at all? Many thanks, Anton.> -----Original Message----- > From: Anton Lokhmotov [mailto:Anton.Lokhmotov at arm.com] > Sent: 22 March 2011 17:40 > To: llvmdev at cs.uiuc.edu > Cc: cfe-dev at cs.uiuc.edu > Subject: RE: [PATCH] OpenCL half support > > Chris Lattner wrote: > > I'm sorry I don't have the patch anymore. Please resend. > Attached. (Copying to cfe-dev, as the patch is dual Clang/LLVM.) > > Anton Korobeynikov wrote: > > PS: my 2 cents: do not forget to handle the existing half fp <-> > float > > conversion intrinsics. > We are not quite sure what to do with them. Can anyone help? > > Best wishes, > Anton.