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