search for: converttoapint

...tendedInteger(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 near...

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

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 bit...

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

...meter types were (i8*, i8*), but now it means something different (probably that the return type is {i32, i8*, i8*}, but I'm not sure). - BinaryOperator::createAnd -> CreateAnd (and similarly for lots of other createX functions) - TargetData::getABITypeSize -> getTypePaddedSize - APFloat::convertToAPInt -> bitcastToAPInt I don't know if any of these count as "major". Thanks, Jay.

Hi All, Please review the 2.5 release notes here: http://llvm.org/docs/ReleaseNotes.html Let me know if you have any additions, improvements, or see any oversights. If you have commit access, please just directly change the document. The release is planned to go out in about 24 hours from now! Thanks! -Chris

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 >

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 &gt...

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