similar to: [LLVMdev] Static functions for APInt

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

As requested by Chris. Neil. -------------- next part -------------- Index: include/llvm/ADT/APInt.h =================================================================== --- include/llvm/ADT/APInt.h (revision 41148) +++ include/llvm/ADT/APInt.h (working copy) @@ -19,9 +19,7 @@ #include <cassert> #include <string> -#define HOST_CHAR_BIT 8 -#define compileTimeAssert(cond) extern int

APFloat is derived from C code using fixed width storage for the matntissa. When converting to C++ I changed it to variable- width storage for space efficiency and generality reasons. Unfortunately this leads to a complication during float->float conversions that I missed that isn't present when using fixed width storage. Dale - I think this solves the issue correctly whilst preserving

Hi Hal, On Sun, Oct 2, 2016 at 7:43 PM Hal Finkel <hfinkel at anl.gov> wrote: > Hi Tim, > > How, in general, are you thinking about doing this? I ask because, as you > clearly know, the double-double format is formed by the sum of two > double-precision numbers, and the various arithmetic operations are formed > mostly in terms of double-precision arithmetic on the

Neil Booth wrote: > Talin wrote:- > >> On the other hand, writing an interpreter means duplicating a lot of >> the functionality that's already in LLVM. For example, consider just >> the problem of float to int conversions: >> >> char B[ (int)3.0 ]; >> >> Generating code for this is relatively simple; Converting >> arbitrary-sized

Talin wrote:- > Well, I may be using it wrong. But looking at APFloat.h, I see four > functions that purport to convert to integer: > > opStatus convertToInteger(integerPart *, unsigned int, bool, > roundingMode) const; > opStatus convertFromSignExtendedInteger(const integerPart *, > unsigned int, >

I have found some internal test failures due to the wrong constant folding on ppc_fp128. As documented in APFloat::PPCDoubleDouble, APFloat doesn't support PowerPC double-double correctly < https://github.com/llvm-mirror/llvm/blob/492acdd450bcdf9837494d6da029ed064f14fc33/lib/Support/APFloat.cpp#L74 >. To support this, we need to add a second tuple of (sign, exponent, significand) to

Talin wrote:- > On the other hand, writing an interpreter means duplicating a lot of > the functionality that's already in LLVM. For example, consider just > the problem of float to int conversions: > > char B[ (int)3.0 ]; > > Generating code for this is relatively simple; Converting > arbitrary-sized APFloats to arbitrary-sized APInts isn't quite as >

Neil Booth wrote: > Talin wrote:- > >> Well, I may be using it wrong. But looking at APFloat.h, I see four >> functions that purport to convert to integer: >> >> opStatus convertToInteger(integerPart *, unsigned int, bool, >> roundingMode) const; >> opStatus convertFromSignExtendedInteger(const integerPart *, >>

More questions on the best way to write a compiler using LLVM: Lets say I have a struct definition that looks like this: const int imageSize = 77; struct A { char B[align(imageSize)]; } ...where 'imageSize' is some small inline function that rounds up to a power of two or something. (A common requirement for textures on 3d graphics cards.) Now, clearly the compiler

Fixed in r79450, along with an additional one of the same nature. Thanks, - Daniel On Thu, Aug 20, 2009 at 7:42 AM, Enea Zaffanella<zaffanella at cs.unipr.it> wrote: > Hello. > > When running clang in Debug mode, I am getting an assertion failure when > parsing the following line: > > float ko = 0x1.1p0; > > Apparently, the recent changes in the use of StringRef

Hello. When running clang in Debug mode, I am getting an assertion failure when parsing the following line: float ko = 0x1.1p0; Apparently, the recent changes in the use of StringRef haven't been propagated to all places. Please find attached the trivial patch. Cheers, Enea Zaffanella. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

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

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

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

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 >

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Tim Northover > In contrast, it's not quite clear what an arithmetic left-shift would > be. If you want to keep x << 1 == x*2 then the logical one already > does this. Only if the left-most (shiftcount + 1) bits are all-0 or all-1. I've used machines that distinguished

Hi, > There is a distinction between logical/arithmetic shift right, but why > not for shift left? The arithmetic right shift has the nice property that it preserves the fact that x >> 1 == x/2 for negative signed numbers (unlike the logical shift). Either because of this or because of other uses I can't think of right now almost all modern CPUs implement it in hardware, and

There is a distinction between logical/arithmetic shift right, but why not for shift left? I'm also a bit confused by one example in the reference manual: <result> = lshr i8 -2, 1 ; yields {i8}:result = 0x7FFFFFFF Is this an error in the manual? The result is supposed to be an i8 yet a i32 is shown. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

It should be compatible with the original patch. However I think that the shared secret should be encoded as a string, too. What does libssh do? > Am 02.11.2013 um 05:46 schrieb Damien Miller <djm at mindrot.org>: > >> On Fri, 1 Nov 2013, Markus Friedl wrote: >> >> Here are three versions (patch against openbsd cvs) >> >> 1) repace nacl w/libsodium,