search for: significandpart

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

...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); -...

...l ConstantFP::get with the GenericValue arguments passed it, but the above repro is a lot simpler and is independent of the JITter. My call stack looks like this: in here it fails this: assert(category == fcNormal || category == fcNaN); Fibonacci.exe!llvm::APFloat::significandParts() Line 360 + 0x39 bytes C++ Fibonacci.exe!llvm::APFloat::zeroSignificand() Line 387 + 0x15 bytes C++ Fibonacci.exe!llvm::APFloat::APFloat(const llvm::fltSemantics & ourSemantics={...}, unsigned __int64 value=1) Line 307 C++ Fibonacci.exe!`...

...l ConstantFP::get with the GenericValue arguments passed it, but the above repro is a lot simpler and is independent of the JITter. My call stack looks like this: in here it fails this: assert(category == fcNormal || category == fcNaN); Fibonacci.exe!llvm::APFloat::significandParts() Line 360 + 0x39 bytes C++ Fibonacci.exe!llvm::APFloat::zeroSignificand() Line 387 + 0x15 bytes C++ I've been working in this area and probably introduced this, but I don't see how: zeroSignificand() sets 'category' to fcNormal before calling significandPar...

...d it, but > the above repro is a lot simpler and is independent of the JITter. > > > > My call stack looks like this: > > > > in here it fails this: assert(category == fcNormal || > category == fcNaN); > > Fibonacci.exe!llvm::APFloat::significandParts() Line > 360 + 0x39 bytes C++ > > Fibonacci.exe!llvm::APFloat::zeroSignificand() Line > 387 + 0x15 bytes C++ I've been working in this area and probably introduced this, but I don't see how: zeroSignificand() sets 'category' to fcNormal befor...

...l ConstantFP::get with the GenericValue arguments passed it, but the above repro is a lot simpler and is independent of the JITter. My call stack looks like this: in here it fails this: assert(category == fcNormal || category == fcNaN); Fibonacci.exe!llvm::APFloat::significandParts() Line 360 + 0x39 bytes C++ Fibonacci.exe!llvm::APFloat::zeroSignificand() Line 387 + 0x15 bytes C++ I've been working in this area and probably introduced this, but I don't see how: zeroSignificand() sets 'category' to fcNormal before calling significandPar...

...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 "what's next?". What do we do to significandParts()? It doesn't make sense to return an array of integerParts for PPCDoubleDouble. Do we examine every call site of significandParts(), and assert/dispatch on fltSemantics? Do we want to build an abstraction between APFloat and the underlying data representation? For example: class APFloatPaylo...

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

...d it, but > the above repro is a lot simpler and is independent of the JITter. > > > > My call stack looks like this: > > > > in here it fails this: assert(category == fcNormal || > category == fcNaN); > > Fibonacci.exe!llvm::APFloat::significandParts() Line > 360 + 0x39 bytes C++ > > Fibonacci.exe!llvm::APFloat::zeroSignificand() Line > 387 + 0x15 bytes C++ > > I've been working in this area and probably introduced this, but I > don't see how: zeroSignificand() sets 'category' to...