Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] [PATCH] OpenCL half support"
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 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
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 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
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 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 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
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 24
2
[LLVMdev] [PATCH] OpenCL half support
On Feb 23, 2011, at 10:01 AM, Anton Lokhmotov wrote:
> 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
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!
>
>
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 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 May 20
1
[LLVMdev] LLVMdev Digest, Vol 83, Issue 33
I have a few pass managers, but only one of them has been initialized with
addPassesToEmitCode, how do I find how many passes are added to a function
pass manager ?
Thank you,
Xin
On Fri, May 20, 2011 at 1:00 PM, <llvmdev-request at cs.uiuc.edu> wrote:
> Send LLVMdev mailing list submissions to
> llvmdev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide
2011 Feb 18
0
[LLVMdev] [PATCH] OpenCL support - update on keywords
Anton,
Would there be any issue with switching the ordering of constant and local?
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Anton Lokhmotov
> Sent: Friday, February 18, 2011 7:27 AM
> To: 'Peter Collingbourne'
> Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
> Subject: [LLVMdev]
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:
2010 Dec 24
0
[LLVMdev] OpenCL support
Abstract:
This message is in response to messages by Krister Wombell and Mike Gist,
and contains a question to Chris Lattner and Devang Patel.
From: Krister Wombell [mailto:kuwerty at gmail.com]
Sent: 23 December 2010 14:10
To: Anton Lokhmotov
Cc: Peter Collingbourne; cfe-dev at cs.uiuc.edu
> I think this tends to work better than storing the names of kernels
> in a list hanging off
2011 Feb 23
0
[LLVMdev] [PATCH] OpenCL support - update on keywords
On Fri, Feb 18, 2011 at 03:27:13PM -0000, Anton Lokhmotov wrote:
> > -----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.
> >
> > >
2011 Feb 25
0
[LLVMdev] [PATCH] OpenCL support - update on keywords
On Thu, Feb 24, 2011 at 1:14 PM, Anton Lokhmotov
<Anton.Lokhmotov at arm.com> wrote:
> Hi Peter,
>
> Many thanks for your prompt review.
>
>> I don't think we should include the word OpenCL in the name of this
>> enum/header. We may very well in the future want to define address
>> space constants for other languages, which should not overlap with
>>