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(const integerPart *, >> unsigned int, >> bool, roundingMode); >> APInt convertToAPInt() const; >> >> The first three convert to an array of integer parts, which (as far as I >> can tell) is not easily convertible into an APInt via any public methods >> I have been able to discover so far. >> >> 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 bitwise representation of the floating-point value? >> > > 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, create your APInt with the appropriate size and > use its buffer as input. APInt has made unfortunate sign choices > though, IIRC it is not sign-extended, so you may need to fudge in > the case of a signed target. This is also why there are two "from" > functions above :( >OK here's a follow-up question: So far the ConstantExpr class has been doing what I want pretty well. However, I'd like to be able to detect overflow / loss of precision when casting constant values so that I can issue the appropriate warning. Since the values are constant, I ought to be able to tell whether or not they can "fit" in the destination type without loss. For ints, this is easy enough using getActiveBits(). For floats, I guess I would need to know whether the fractional part of the number is zero or not, and I'd need floating-point equivalents to the various integer min and max values, so that I could compare them with the APFloat. What would be a good technique for accomplishing this?> Neil. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
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, create your APInt with the appropriate size and > > use its buffer as input. APInt has made unfortunate sign choices > > though, IIRC it is not sign-extended, so you may need to fudge in > > the case of a signed target. This is also why there are two "from" > > functions above :( > > > OK here's a follow-up question: So far the ConstantExpr class has been > doing what I want pretty well. However, I'd like to be able to detect > overflow / loss of precision when casting constant values so that I can > issue the appropriate warning. Since the values are constant, I ought to > be able to tell whether or not they can "fit" in the destination type > without loss. For ints, this is easy enough using getActiveBits(). For > floats, I guess I would need to know whether the fractional part of the > number is zero or not, and I'd need floating-point equivalents to the > various integer min and max values, so that I could compare them with > the APFloat. > > 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 wrote for my own C compiler front end, which catches and diagnoses these constant-folding issues. It, in C, has a different implementation of APInt that additionally provides this information for integer operations, like APFloat does for floating operations, making this kind of analysis easy. The static methods of APInt are essentially part of that. If LLVM's APFloat wrapper isn't conveying the info it is given by APFloat, it needs to be improved :) Neil.
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 IRight. 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.> If LLVM's APFloat wrapper isn't conveying the info it is given > by APFloat, it needs to be improved :)No, it doesn't. The LLVM constant classes are intended for the optimizer and IR, not for a front-end to use. -Chris -- http://nondot.org/sabre/ http://llvm.org/