similar to: [LLVMdev] Complex constant expressions?

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

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

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 *, >>

This adds a bunch of static functions that implement unsigned two's complement bignum arithmetic. They could be used to implement much of APInt, but the idea is they are enough to implement APFloat as well, which the current APInt interface is not suited for. Neil. -------------- next part -------------- Index: include/llvm/ADT/APInt.h

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

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:- > > Only two convert to integer. The convertToAPInt is unfortunately > > named; I'm not sure what it does but suspect it captures bitpatterns > > like you suggest. > > > > convertToInteger is the function I'm responsible for and it does > > float->int conversion according to IEEE754. If you want to place > > it in an APInt,

I'm breaking this out from LLVM asserts thread. Here are all the assertions in APInt I consider should be recoverable: APInt::APInt: bitwidth too small Null pointer detected! APInt::getBitsNeeded: Invalid string length string is only a minus! Invalid radix APInt::fromString: Radix should be 2, 8, 10, or 16! Invalid string length string is only a minus Insufficient bit width Invalid digit in

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 Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

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:

On Jan 23, 2008, at 5:10 AM, Neil Booth wrote: > Talin wrote:- >> APInt convertToAPInt() const; >> >> The last function doesn't appear to convert the APFloat into the >> nearest >> integer equivalent, since my experiments with it returned completely >> unexpected values; I'm assuming that what is returned is an APInt >> containing the

--- Hi, this is still WIP, but already passes piglit's s3tc-teximage, s3tc-texsubimage and fbo-generatemipmap-formats(s3tc tests) and even Wolfenstein:Enemy-Territory works on my nv25. It's based on Ben's newlib branch. I have few issues though: 1) So far it needs libtxc_dxtn, but I might expose the s3tc extensions even without encoder using driconf option - Is that desirable? 2)

Hi, I've been playing around with the APFloat class lately and I came across behavior I was not expecting based on reading the implementation comments and I'm wondering if it's a bug or intentional. The behavior concerns converting an APFloat to a string and back again. In the implementation of ``APFloat::toString(...)`` you can specify ``FormatPrecision`` as 0. The method comments

On Fri, 25 Jan 2008, Neil Booth wrote: >> What would be a good technique for accomplishing this? > The APFloat functionality I wrote is the only means I'm aware of > in LLVM, via the return value. APFloat is derived from C code I Right. Use of APFloat and AP[S]Int directly is the way to do this. It would be useful to extend APSInt to capture information about overflow. >

Hi, I'm trying to separate the Support, System, ADT and Config header files into the support module, per previous plans. However, APFloat.h is not self-contained: APFloat.h:105:43: error: llvm/Bitcode/SerializationFwd.h: No such file or directory APFloat.h:106:37: error: llvm/CodeGen/ValueTypes.h: No such file or directory As you can see, APFloat.h depends on things that are not in the ADT,

On Aug 19, 2009, at 9:36 PM, Erick Tryzelaar wrote: > I'm breaking this out from LLVM asserts thread. Here are all the > assertions in APInt I consider should be recoverable: > > APInt::APInt: > bitwidth too small > Null pointer detected! Hi Eric, As we discussed on IRC, I don't think there is any reason for the implementation of these methods to check these

On Dec 8, 2007, at 1:13 AM, Reid Spencer wrote: > Hi, > > I'm trying to separate the Support, System, ADT and Config header > files > into the support module, per previous plans. However, APFloat.h is not > self-contained: > > APFloat.h:105:43: error: llvm/Bitcode/SerializationFwd.h: No such file > or directory > APFloat.h:106:37: error: