Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] [PATCH] OpenCL half support"
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
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 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
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 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
2011 Apr 04
0
[LLVMdev] [PATCH] OpenCL half support
Chihong,
I notice that IEEE-754-2008 does in fact define a
16-bit floating point standard now,
does your processor conform to that standard, if so there should be
no objection to adding fp16 to LLVM
and you should have no problem using it, at least that's what I think
Chris is trying to say (?).
IEEE-754-2008 fp16: 1-bit sign, 5-bit exponent, 10-bit
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
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!
>
>
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:
2013 Jan 23
0
[LLVMdev] Half Float fp16 Native Support
> i understand that is not right but this was the only way not to use the fadd
> for f32 "add.s" and use the "add.h" what ever i tried llvm moved everything
> to the float registers and did add.s and not the half add.h
It seems you do not understand the issue.
Half floating poing operations can be done in two ways:
1. Storage-only (fp16 is used to store value, all
2013 Jan 22
2
[LLVMdev] Half Float fp16 Native Support
i understand that is not right but this was the only way not to use the fadd
for f32 "add.s" and use the "add.h" what ever i tried llvm moved everything
to the float registers and did add.s and not the half add.h
is there any trick to do that? i tried a lot but with no luck
--
View this message in context:
2011 Feb 21
3
[LLVMdev] [PATCH] OpenCL support - update on keywords
> > > > +enum OpenCLAddressSpace {
> > > > + OPENCL_PRIVATE = 0,
> > > > + OPENCL_GLOBAL = 1,
> > > > + OPENCL_LOCAL = 2,
> > > > + OPENCL_CONSTANT = 3
> > > > +};
> -----Original Message-----
> From: Villmow, Micah [mailto:Micah.Villmow at amd.com]
>
> Anton,
> Would there be any issue with switching
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
2012 May 17
0
[LLVMdev] [PATCH] OpenCL half support
Hi David,
Many thanks for the comments!
> Tha 0xH format should be described in LangRef.html alongside
> 0xK<hex> and 0xM<hex>
Done.
> Declaration of "int shiftcount" should be moved to smallest nesting
> possible, right after "if ( const ConstantFP ..." at line 710
>
> (The code makes a lot more sense with a good comment on the
2016 Mar 05
2
Adding 'v16f16' to tablegen
I have been able to adapt the main LLVM sources to work with vectors of 16 x
FP16 values and I have introduced the 'v16f16' data type to CLang and LLVM,
but I am stumped on how to get TableGen to recognise this type. At the
moment I am trying to optimise the calling convention code, and whenever I
refer to 'v16f16' I get a crash in TableGen (unrecognised type).
Unfortunately I
2012 Nov 02
2
[LLVMdev] Half Float fp16 Native Support
hi all,
i am trying to implement native support for fp16 in llvm-3.1
i have already used the opencl patch for clang so the IR that is generated
is correct.
i tried to add some code so the the fp16 type is handled correctly but no
luck.
We have a target that has native fp16 units and tried to run a simple
program
int main ()
{
__fp16 a,b,c,d;
a= 1.1;
b=2.2;
c=3.3;
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
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: