search for: integerpart

...================================= --- include/llvm/ADT/APInt.h (revision 41083) +++ include/llvm/ADT/APInt.h (working copy) @@ -19,8 +19,16 @@ #include <cassert> #include <string> +#define HOST_CHAR_BIT 8 +#define compileTimeAssert(cond) extern int CTAssert[(cond) ? 1 : -1] +#define integerPartWidth (HOST_CHAR_BIT * sizeof(llvm::integerPart)) + namespace llvm { + /* An unsigned host type used as a single part of a multi-part + bignum. */ + typedef uint64_t integerPart; + //===----------------------------------------------------------------------===// //...

...================================== --- 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 CTAssert[(cond) ? 1 : -1] -#define integerPartWidth (HOST_CHAR_BIT * sizeof(llvm::integerPart)) +#define COMPILE_TIME_ASSERT(cond) extern int CTAssert[(cond) ? 1 : -1] namespace llvm { @@ -29,6 +27,9 @@ bignum. */ typedef uint64_t integerPart; + const unsigned int host_char_bit = 8; + const unsigned int integerPartWidth = hos...

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

...ble 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 "what's next?". What do we do to significandParts()? It doesn't make sense to return an array of integerParts for PPCDoubleDoubl...

...rary-sized APInts isn't quite as >> easy. >> > > APFloat::convertToInteger does just this. Why can't you use it? > 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, bool, roundingMode); opStatus convertFromZeroExtendedInteger(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:- > 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, > bool, roundingMode); > opStatus convertFromZeroExtendedInteger(const integerPart *, &...

...()) { + /* Handle storage complications. If our new form is wider, + re-allocate our bit pattern into wider storage. If it is + narrower, 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; -...

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 *, >> unsigned int, >> bool, roundingMode); >> opStatus convertFromZeroExtendedInteger(con...

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

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:

...gt; > Cheers, > Enea Zaffanella. > > > Index: lib/Support/APFloat.cpp > =================================================================== > --- lib/Support/APFloat.cpp     (revision 79510) > +++ lib/Support/APFloat.cpp     (working copy) > @@ -2153,7 +2153,7 @@ >     integerPart hex_value; > >     if(*p == '.') { > -      assert(dot == 0); > +      assert(dot == s.end()); >       dot = p++; >     } > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiu...