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 APFloats to arbitrary-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, 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? -- Talin
cradnil
2008-Jan-23 06:48 UTC
[LLVMdev] A potential single buffer overflow in program.inc for win32
// First, determine the length of the command line.
unsigned len = 0;
for (unsigned i = 0; args[i]; i++) {
len += strlen(args[i]) + 1;
if (strchr(args[i], ' '))
len += 2;
}
// Now build the command line.
char *command = reinterpret_cast<char *>(_alloca(len)); // should use
len+1 to fix this
char *p = command;
for (unsigned i = 0; args[i]; i++) {
const char *arg = args[i];
size_t len = strlen(arg);
bool needsQuoting = strchr(arg, ' ') != 0;
if (needsQuoting)
*p++ = '"';
memcpy(p, arg, len);
p += len;
if (needsQuoting)
*p++ = '"';
*p++ = ' ';
}
*p = 0; // this may write beyond the boundary
2008-01-23
cradnil
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080123/62cc56be/attachment.html>
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 :( Neil.
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 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.It's described pretty well, I thought: // This function creates an APInt that is just a bit map of the floating // point constant as it would appear in memory. It is not a conversion, // and treating the result as a normal integer is unlikely to be useful. APInt APFloat::convertToAPInt() const { ....
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 > >