Displaying 20 results from an estimated 5000 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 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 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
> -----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
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
> 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
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;
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
2017 Dec 04
2
[RFC] Half-Precision Support in the Arm Backends
Hi,
I am working on C/C++ language support for the Armv8.2-A half-precision
instructions. I've added support for _Float16 as a new source language type to
Clang. _Float16 is a C11 extension type for which arithmetic is well defined, as
opposed to e.g. __fp16 which is a storage-only type. I then fixed up the
AArch64 backend, which was mostly straightforward: this involved making
operations
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:
2013 Jan 22
2
[LLVMdev] Half Float fp16 Native Support
after a long time i managed to make a progress with this problem. i can store
and load fp16 as i16 in to some registers and do an add instruction. the
problem now is that this messes up the real i16 (short, unsigned short).
i have
def FADD_H : NemaCorePseudo< (outs HGR16:$fd), (ins HGR16:$fs, HGR16:$ft),
"add.h\t$fd, $fs, $ft", [(set (i16 HGR16:$fd),(i16 (f32_to_f16 (f32 (fadd
(f32
2012 Apr 11
0
[LLVMdev] float16/half float support situation? (and a problem)
OpenCL defines half data type, and it seems clang accepts this and
generates code for it.
The backend support for operations with fp16 seems to be missing and it
works (or should work?) by converting these to fp32 for the actual
calculations?
But I'm having problems with this.
first I just tried to use fp16 data type, without any support in
backend. This was expected to fail.
I got
2013 Jan 22
0
[LLVMdev] Half Float fp16 Native Support
> def FADD_H : NemaCorePseudo< (outs HGR16:$fd), (ins HGR16:$fs, HGR16:$ft),
> "add.h\t$fd, $fs, $ft", [(set (i16 HGR16:$fd),(i16 (f32_to_f16 (f32 (fadd
> (f32 (f16_to_f32 (i16 HGR16:$fs))),
> (f32 (f16_to_f32 (i16 HGR16:$ft))))))))]>;
>
> so i can have a half floating point add two half point variables and seems
> to work fine.
This does not look right. Note
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
2012 Nov 02
0
[LLVMdev] Half Float fp16 Native Support
Hi Nikos
> and when i try to call llc produces this error
>
> LLVM ERROR: Cannot select: 0x234bab0: f16 = fadd 0x234b8b0, 0x234c2b0
> [ORD=9] [ID=29]
This error suggests things are working on the generic LLVM side (as
I'd expect). It's what I'd expect to see for your code snippet if
there wasn't a target-specific pattern that could handle the addition
properly 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
2018 Jan 18
1
[RFC] Half-Precision Support in the Arm Backends
Hi Sjoerd,
For ISel, I think having a separate register class will give you less headache. I wondering if you could get away with not touching the instructions descriptions at all, instead defining external pattens for the FullFP16 case, like so:
def VCVTBHS: ASuI<0b11101, 0b11, 0b0010, 0b01, 0, (outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpCVTSH, "vcvtb",
2018 Jan 18
0
[RFC] Half-Precision Support in the Arm Backends
I would like to revive this thread, as I am struggling a lot with the FP16
implementation in the ARM backend. My implementation in
https://reviews.llvm.org/D38315 is finished (except one case), but a more
robust alternative implementation was suggested. One can indeed argue that my
current implementation is a bit fragile, because it involves manually patching
up the isel dags for a few cases. The
2007 Aug 18
1
[LLVMdev] Soft floating point support
This patch supplies software IEEE floating point support.
The comment from the patch reproduced below says all there is
to say.
This patch contains the prior "cleanup" patch; please don't apply
that one.
Please let me know of any bugs. It is tested reasonably well,
but until I put together random tests it's hard to have 100%
confidence.
Neil.
/* A self-contained host- and