search for: significand

...to APFloat IEEEdouble in > the implementation of the various operations. > > As such, one option might be that, when PPCDoubleDouble fltSemantics are > selected, the exponent and sign are ignored, and we just store the data for > the two double-precision floating-point numbers in the significand. We > might even do this directly, by making the significand something like this: > > union Significand { > integerPart part; > integerPart *parts; > APFloat *fltparts; // used for PPCDoubleDouble > } significand; > We can do this, but my concern is "wh...

...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 APFloat. I wonder where should I start to change, so that it's less hacky? I certainly expect refactoring to come. :) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160930/789e507d/attachmen...

...perhaps not optimize, accordingly. At present, underflow tininess is detected after rounding; it should be straight forward to add support for the before-rounding case too. Non-zero finite numbers are represented internally as a sign bit, a 16-bit signed exponent, and the significand as an array of integer parts. After normalization of a number of precision P the exponent is within the range of the format, and if the number is not denormal the P-th bit of the significand is set as an explicit integer bit. For denormals the most significant bit is shifted r...

On Wed, Apr 27, 2011 at 12:51 AM, John McCall <rjmccall at apple.com> wrote: > On Apr 26, 2011, at 2:07 AM, Joe Armstrong wrote: >> Compiles (via clang) to: >> >>  ; ModuleID = 'test101.c' >>  target datalayout = >>

...T the 64 bit representation > with the low order > 32 bits zeroed - it is the 62 bit representation with the low order 28 > bits zeroed. > > Why 28 bits? - 32 bits might be understandable but not 28. I bet the low 29 bits are zeroed. That is the difference between the 52 bit double significand and the 23 bit float significand. This is what you get if 3.145 is first converted to a float and then to a double. /jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110427/00d43f46/attachment.html&gt...

...we ignore the excess parts, but if narrowing to a + single part we need to free the old storage. */ + if (newPartCount > oldPartCount) { integerPart *newParts; newParts = new integerPart[newPartCount]; APInt::tcSet(newParts, 0, newPartCount); - APInt::tcAssign(newParts, significandParts(), partCount()); + APInt::tcAssign(newParts, significandParts(), oldPartCount); freeSignificand(); significand.parts = newParts; - } else if (newPartCount==1 && newPartCount < partCount()) { - integerPart newPart; - - APInt::tcSet(&newPart, 0, newPartCount);...

...g is set and the result is a quiet NaN (much more common). >> (b) x is a quiet NaN on a platform that does not propagate NaN payloads (e.g. ARM with "default nan" bit set in fpscr). > > What do you get in this case? A NaN whose “payload” (i.e. the bits in what would be the significand field of a normal number) may be different from those of the input NaN. >> (c) x is +0.0 and the rounding mode is round down. > > So far rounding modes were always ignored in LLVM AFAIK. I believe you’re right about this, but it would be nice to not paint ourselves into a corner w.r...

...he extension to converting reals to binary representation. The decimal part can be done like this: decbase <- function(x, n=52, base=2) { if(n) { x <- x*base paste(trunc(x), decbase(x%%1, n-1, base), sep="") } } n=52 default because that's the number of bits in the significand of a 64-bit float. Now, `decbase(0.1)` is a bit curious in that the 0.1 is going to be converted to a binary float by the interpreter ... and then re-converted by `decbase`, so really I should insist on character format for the number I want to convert. But anyway I do get the right answer up to t...

Le 3 juin 2010 à 16:00, Martin Guy a écrit : > [off list] > >> 0.8f get converted in 0x3FE99999A0000000 by LLVM > > single precision > >> http://babbage.cs.qc.edu/IEEE-754/Decimal.html gives: >> >> 0x3FE999999999999A instead and this value cannot be read back by "llc"... > > double precision > > M Well For float 0.8 :

Hi Arsen, On Oct 9, 2013, at 4:53 AM, Arsen Hakobyan <artinetstudio at gmail.com> wrote: > Hi all, > > I have the following test case: > #define FLT_EPSILON 1.19209290E-7 > > int err = -1; > int main() > { > float a = 8.1; > if (((a - 8.1) >= FLT_EPSILON) || ((a - 8.1) <= -FLT_EPSILON)) { //I am > using FLT_EPSILON to check whether (a != 2.0).

...ion without any rounding. I assume what you mean here is only one rounding mode, i.e. round-nearest-ties-to-even. Yes. I was emphasizing that rounding modes aren't part of the API. >> - Digits represented simply as a 32-bit or 64-bit integer. > > Isn’t this the same as the significand of an IEEE float? If you go with 64-bit, it sounds like you’re defining something very close to Intel’s FP80. Yup. The `uint64_t` version is similar to a non-conforming and slow FP80 that's always in denormal mode, but the *same* non-conforming on every platform.

...a quiet NaN (much more common). >> >>>> (b) x is a quiet NaN on a platform that does not propagate NaN payloads (e.g. ARM with "default nan" bit set in fpscr). >>> What do you get in this case? >> A NaN whose “payload” (i.e. the bits in what would be the significand field of a normal number) may be different from those of the input NaN. >> >>>> (c) x is +0.0 and the rounding mode is round down. >>> So far rounding modes were always ignored in LLVM AFAIK. >> I believe you’re right about this, but it would be nice to not paint...

Hi all, I have the following test case: #define FLT_EPSILON 1.19209290E-7 int err = -1; int main() { float a = 8.1; if (((a - 8.1) >= FLT_EPSILON) || ((a - 8.1) <= -FLT_EPSILON)) { //I am using FLT_EPSILON to check whether (a != 2.0). err = 1; } else { err = 0; } return 0; } with -O3 optimization level clang generates already incorrect LLVM IR: ; Function Attrs:

...s a developer. :-( > I would say hacking on libvirt windows is easy, as long as you have a windows (to run) & a fedora (to build). Some issues could even be debugged with wine (yes!) The few docs I saw about porting Linux software for windows (like gimp) makes it look very hard, involving a significand investment in time just to get started and a deep knowledge about both platforms. Would you be able to provide a HOW-TO for virsh and maybe virt-viewer? I'm not telling I'd be able to spare the time, but I'd give it a try before calling defeat. []s, Fernando Lozano

...Buffer.set_size(Start + N); - memcpy(&Buffer[Start], Str, N); - } template <unsigned N> void append(SmallVectorImpl<char> &Buffer, const char (&Str)[N]) { - append(Buffer, N, Str); + Buffer.append(Str, Str + N - 1); } /// Removes data from the given significand until it is no more

I'm currently working on stripping usage of `UnsignedFloat` out of `-block-freq`. Before I finish... I propose adding a soft-float class to llvm/Support/ or llvm/Analysis/. - Portable (unlike hard-floats). - Well-defined for all platforms and safe to use in code. - Easy to use and reason about (unlike `APFloat`). - Uses operators. - No special numbers. - Every

On Aug 28, 2014, at 3:03 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote: > Hi Owen, > > On 27/08/14 19:06, Owen Anderson wrote: >> >>> On Aug 27, 2014, at 6:34 AM, Duncan Sands <duncan.sands at deepbluecap.com >>> <mailto:duncan.sands at deepbluecap.com>> wrote: >>> >>> I think you should try to get LLVM floating

...hacking on libvirt windows is easy, as long as you have a >> windows (to run) & a fedora (to build). Some issues could even be debugged >> with wine (yes!) >> > The few docs I saw about porting Linux software for windows (like gimp) > makes it look very hard, involving a significand investment in time just to > get started and a deep knowledge about both platforms. Would you be able to > provide a HOW-TO for virsh and maybe virt-viewer? I'm not telling I'd be > able to spare the time, but I'd give it a try before calling defeat. > > > []s, Fernand...

...I assume what you mean here is only one rounding mode, i.e. round-nearest-ties-to-even. >> Yes. I was emphasizing that rounding modes aren't part of the API. >> >>>> - Digits represented simply as a 32-bit or 64-bit integer. >>> Isn’t this the same as the significand of an IEEE float? If you go with 64-bit, it sounds like you’re defining something very close to Intel’s FP80. >> Yup. The `uint64_t` version is similar to a non-conforming and slow FP80 >> that's always in denormal mode, but the *same* non-conforming on every >> platform. &g...

Hi, >> I'm trying to use virsh and virt-viewer on Windows. I'm running the >> latest binaries from http://spice-space.org/download.html, that is, >> virt-viewer-x64-0.5.7.msi on a Windows 7 64-bits computer. >> >> So far I got remote-viewer.exe to work, after some pain. But have no >> sucess using virt-viewer.exe and virsh.exe. Are they supposed to