similar to: [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

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

> 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

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

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

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

Hi all, I'm authoring a C interface to the LLVM IR type system. Since this is Really Quite Tedious, I would like to solicit opinions before I get too far down any paths that seem offensive. I've attached the header, where I've mapped a portion of Module and most of Type and its subclasses. This is working, and I've built ocaml bindings on top of it.[1] My intent is to

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Tuesday, December 01, 2015 1:01 AM > To: Tim Shen > Cc: Gao, Yunzhong; llvm-dev at lists.llvm.org; Kit Barton; Nemanja Ivanovic > Subject: Re: [llvm-dev] Endianness for multi-word types > > ----- Original Message ----- > > From: "Tim Shen via llvm-dev" <llvm-dev at

On Mon, Nov 30, 2015 at 7:24 PM Gao, Yunzhong < yunzhong_gao at playstation.sony.com> wrote: > According to > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html, > "The high-order double-precision value (the one that comes first in > storage) must have the larger magnitude." > > So the order of the two doubles in your fp128 is not affected by the

All, Here is the second revision of the proposal for a complex type in LLVM. It clarifies a few things that came up during discussion and adds additional operations for complex types. -David Proposal to Support Complex Operations in LLVM ---------------------------------------------- Revision History v1 - Initial proposal [1] v2 - This proposal - Added complex of

Hi, I'm recently trying to investigate ppc_fp128 related problem. Here is a minimal C++ test case that seems wrongly compiled: long double id(long double a) { return a; } bool f(long double x) { return id(__builtin_fabsl(x)) >= 0; } int main() { if (f(-123.l)) { return 0; } return 1; } The program compiled with command: clang++ -static -target powerpc64le-linux-gnu bad.cc

Hi, There’s growing interest among our users to make better use of dedicated hardware instructions for complex math and I would like to re-start the discussion on the topic. Given that this original thread was started a while ago apologies if I missed anything already discussed earlier on the list or the round-table. The original mail is quoted below. In particular, I’m interested in the AArch64

Ahead of the Wednesday’s roundtable at the developers’ conference, here is version three of the proposal for first-class complex types in LLVM. I was not able to add Krzysztof Parzyszek’s suggestion of a “cunzip” intrinsic returning two vectors as I could not find examples of intrinsics that return two values at the IR level. The Hexagon intrinsics declared to return two values do not actually

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

"Finkel, Hal J." <hfinkel at anl.gov> writes: > I think that it's really important that we're specific about the goals > here. Exactly what kinds of optimizations are we aiming to (more-easily) > enable? There certainly exists hardware with instructions that help > vectorize complex multiplication, for example, and having a builtin > complex type would

Many thanks for getting back. 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. BTW, in the doc I was reading there was not mention about Quad size numbers, decimal numbers and extended precision numbers. http://llvm.org/docs/LangRef.html#type-system -------------- next part -------------- An

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

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

Is the llvm backend (legalize, isel, etc.) currently capable of handling type f128? I am trying to emit a call to __subtf3 when I compile the following bitcode: define fp128 @f1(fp128 %a0, fp128 %a1) nounwind readnone { entry: %sub = fsub fp128 %a0, %a1 ret fp128 %sub } This is for the Mips backend.

> 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: