Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] [PATCH] OpenCL half support"
2011 Feb 23
0
[LLVMdev] [PATCH] OpenCL half support
Please find attached Clang/LLVM patches for supporting 'half' - the
half-precision floating-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
2011 Mar 22
1
[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
2011 Mar 21
2
[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
2011 Mar 21
0
[LLVMdev] [PATCH] OpenCL half support
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
2011 Mar 18
5
[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
2011 Mar 18
0
[LLVMdev] [PATCH] OpenCL half support
> -----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
2011 May 22
2
[LLVMdev] [PATCH] OpenCL half support
On May 20, 2011, at 6:48 AM, Anton Lokhmotov wrote:
> Hi Chris,
>
>> Sorry for dropping this. Can you resend your current patch? Lets just
>> start and iterate on the llvm patch first.
> Please find the LLVM patch attached.
Hi Anton,
This looks like a great start, but it needs a lot of testcases showing that these things constant fold, handle conversions correctly, and
2011 Mar 18
3
[LLVMdev] [PATCH] OpenCL half support
<!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
2012 May 24
1
[LLVMdev] [PATCH] OpenCL half support
Could someone please commit the attached patches?
/*
Approved by:
- Anton Korobeynikov:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-May/049849.html
- Micah Villmow:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-May/049848.html
- David Neto:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-May/049705.html
*/
Many thanks,
Anton.
-----Original Message-----
From: Anton Lokhmotov
2012 May 17
3
[LLVMdev] [PATCH] OpenCL half support
looks good here.
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Anton Lokhmotov
> Sent: Thursday, May 17, 2012 4:51 AM
> To: 'David Neto'
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] [PATCH] OpenCL half support
>
> Hi David,
>
> Many thanks for the comments!
>
>
2007 Sep 14
0
[LLVMdev] C interface
Hello Gordon,
I'm part of the felix dev team, and I've been interested in making a
backend for felix in llvm. It's very exciting to hear that you're making
an ocaml interface to llvm. Do you have any of the libraries exposed to
the public yet? Also, what license do you plan on using for the code?
Felix is bsd, like llvm, so if there's any chance that you'll use a
2013 Sep 09
0
[LLVMdev] IEEE 754-2008 | ISO/IEC TR 18037
> This will come in handy if you do not have a floating point unit. Also for
> speed in some cases.
>
> To be generic as possible it might be good to have this.
The goal isn't really maximum generality, but support for languages
that people care about. Currently that's mostly C and C++, with a
smattering of features for some others.
But features almost never get added
2012 May 11
2
[LLVMdev] [PATCH] OpenCL half support
I've got comments on the code change. The test cases look ok, but I
haven't fully checked the math on the half-values.
I checked with reference to trunk top-of-tree at revision 156617. I
have not compiled the code.
lib/AsmParser/LLLexer.cpp
Adds support to parse format: 0xH<hexdigits>
Tha 0xH format should be described in LangRef.html alongside
0xK<hex> and
2011 Feb 21
0
[LLVMdev] [PATCH] OpenCL support - update on keywords
The problem is that we use the ordering private, global, constant and local, and this is the same ordering that is used on Apple as well. As we already have OpenCL binaries out in public, making the change is problematic as we want to keep backward compatibility at all costs.
Thanks,
Micah
> -----Original Message-----
> From: Anton Lokhmotov [mailto:Anton.Lokhmotov at arm.com]
> Sent:
2012 May 18
1
[LLVMdev] [PATCH] OpenCL half support
> Anton, would it be possible to add information to the documentation
> here:
> http://llvm.org/docs/BitCodeFormat.html
Sure!
Any further comments?
Many thanks,
Anton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: half-doc.patch
Type: application/octet-stream
Size: 657 bytes
Desc: not available
URL:
2012 May 17
0
[LLVMdev] [PATCH] OpenCL half support
Anton, would it be possible to add information to the documentation here:
http://llvm.org/docs/BitCodeFormat.html
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Villmow, Micah
> Sent: Thursday, May 17, 2012 9:04 AM
> To: Anton.Lokhmotov at arm.com; 'David Neto'
> Cc: llvmdev at cs.uiuc.edu
>
2011 Mar 18
0
[LLVMdev] [PATCH] OpenCL half support
> 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.
FWIW: there are already intrinsics for such conversions (currently
only used in ARM backend).
There is no need for new type if you want just to convert stuff.
--
With
2011 Jul 14
1
[LLVMdev] [PATCH] OpenCL half support
On Jul 13, 2011, at 4:26 AM, Anton Lokhmotov wrote:
> Hi Chris,
>
> We have updated the half patch for TOT. Could you review please?
Sorry for the delay, some thoughts:
+++ b/include/llvm/Bitcode/LLVMBitCodes.h
@@ -110,10 +110,12 @@ namespace bitc {
TYPE_CODE_METADATA = 16, // METADATA
TYPE_CODE_X86_MMX = 17, // X86 MMX
+
+ TYPE_CODE_HALF = 18, // IEEE
2011 Feb 18
6
[LLVMdev] [PATCH] OpenCL support - update on keywords
> -----Original Message-----
> From: Peter Collingbourne [mailto:peter at pcc.me.uk]
> Sent: 04 January 2011 21:42
> To: Anton Lokhmotov
> Cc: cfe-dev at cs.uiuc.edu
> Subject: Re: OpenCL support
>
> Here are my comments on the second patch.
>
> > +enum OpenCLAddressSpace {
> > + OPENCL_PRIVATE = 0,
> > + OPENCL_GLOBAL = 1,
> > + OPENCL_LOCAL
2010 Dec 24
2
[LLVMdev] Function-level metadata for OpenCL (was Re: OpenCL support)
On Tue, Dec 21, 2010 at 07:17:40PM -0000, Anton Lokhmotov wrote:
> > From: Peter Collingbourne [mailto:peter at pcc.me.uk]
> > Sent: 20 December 2010 20:11
> > As with __local variables, it may be that "kernelness" cannot be
> > represented in a standard form in LLVM. For example on a CPU a
> > kernel function may have an additional parameter which is a