Displaying 20 results from an estimated 800 matches similar to: "Adding 'v16f16' to tablegen"
2015 Dec 11
2
bitcode versioning
Hi Mehdi and my apologies for the delay in responding - the day job got in the way :-)
Our target is still out-of-tree so my reasons for extending the IR would be eliminated if we were a proper part of LLVM, which I would like to do when the time is right for us.
My extensions are quite simple really, and I expect that they will be wanted in the TRUNK sometime anyway.
At the moment I only have
2015 Dec 03
2
bitcode versioning
Is there going to be a formal interface/API for this version-block information? I have had to "extend" the IR and bitcode representations several times to address absences/limitations in the handling of various vector types, in particular FP16 vector types; and it would be really useful if I had a "standard" way of doing this, and identifying that my dialect was different.
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
2014 Jun 19
2
[LLVMdev] __fp16 suport in llvm back-end
Hi, all:
I am trying to test half float point support in llvm, I found clang can generate bitcode for __fp16, while llc can't generate code for it, the error message is like this
LLVM ERROR: Cannot select: 0x26a68e0: i16 = fp32_to_fp16 0x26a67d8 [ORD=2] [ID=4]
0x26a67d8: f32,ch = CopyFromReg 0x2693060, 0x26a66d0 [ORD=2] [ID=3]
0x26a66d0: f32 = Register %vreg1 [ID=1]
In function: test
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
2019 Sep 05
2
ARM vectorized fp16 support
Thanks for reply. I was using LLVM 8.0. Let me try trunk and will let
you know if it works.
On Wed, Sep 4, 2019 at 11:19 PM Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote:
>
> Hi,
> Which version of Clang are you using? I do get a "vfma.f16" with a recent trunk build. I haven't looked at older versions and when this landed, but we had an effort to plug the remaining
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 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
2019 Sep 05
2
ARM vectorized fp16 support
Hi,
I'm trying to compile half precision program for ARM, while it seems
LLVM fails to automatically generate fused-multiply-add instructions
for c += a * b. I'm wondering whether I did something wrong, if not,
is it a missing feature that will be supported later? (I know there're
fp16 FMLA intrinsics though)
Test programs and outputs,
$ clang -O3 -march=armv8.2-a+fp16fml
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
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
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:
2014 Jul 10
2
[LLVMdev] Help!!!!Help!!!! " LLVM ERROR: Cannot select: 0x9fc9680: i32 = fp32_to_fp16 0x9fc0750 [ID=16] " problem!!!!!!!!!!!!!!!!!!
Hi Andrea Thank you your replying. I do like your letter. Add following to line to MipsISelLowering.cpp. As your words, @llvm.convert.to.fp16 can compile successfully. However, the runtime is not right.
+ setOperationAction(ISD::FP16_TO_FP32, MVT::f32, Expand);+ setOperationAction(ISD::FP32_TO_FP16, MVT::i32, Expand);
Robin
yalong at multicorewareinc.com
From: Andrea Di
2014 Jul 14
5
[LLVMdev] RFC: Do we still need @llvm.convert.to.fp16 and the reverse?
Hi all,
What do people think of doing away with the @llvm.convert.to.fp16 and
@llvm.convert.from.fp16 intrinsics, in favour of using "half" and
fpext/fptrunc? [1]
It looks like those intrinsics originally date from before "half"
actually existed in LLVM, and of course the backends have grown up
assuming that's what Clang will produce, so we'd have to improve their
2018 Jan 17
0
Does it make sense to upstream some MVT's?
Hi Sean,
I had to add ‘v16f16’ to our out-of-tree target, and this was to primarily to allow me to express lowering for all the OpenCL types (well, except for the ‘v3T’ types).
The trend does seem to be towards larger bit-width SIMD registers, and as you say this will increase in time; but perhaps instead of using a discrete enumeration combined with additional entries in several
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",