Hi Tim, Thanks for the hint. I tried the following, (it's a C interface since that's what I need it for) where a and b are the top and bottom halves of the 128 bit value, LLVMValueRef TestConst(LLVMContextRef C, uint64_t a, uint64_t b) { Type *ty = Type::getFP128Ty(*unwrap(C)); ArrayRef<uint64_t> ar[2] = {a,b}; APInt ai(128,*ar); APFloat quad(APFloat::IEEEquad(), ai); return wrap(ConstantFP::get(ty,quad)); } but for 1.0e0 it returns zero store fp128 0xL00000000000000000000000000000000, fp128* %e, align 16 and for 1.23e0 returns this, which is wrong. (that repeating 147AE is a bit weird) store fp128 0xLE147AE147AE147AE0000000000000000, fp128* %e, align 16 so I'm obviously doing something wrong. Regards Peter On Wed, Apr 10, 2019 at 9:44 PM Tim Northover <t.p.northover at gmail.com> wrote:> Hi Peter, > > On Wed, 10 Apr 2019 at 08:01, Peter McKinna via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Just wondering if it's possible to construct a 128 bit quad precision > floating point > > constant without converting the value back to a string. > > It looks like the constructor that takes an APInt treats it as a > bag-of-bits representation according to IEEE float. It eventually ends > up at https://llvm.org/docs/doxygen/APFloat_8cpp_source.html#l03098 as > far as I can tell. > > Cheers. > > Tim. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190411/cc091cc7/attachment.html>
This code line of code might not work correctly ArrayRef<uint64_t> ar[2] = {a,b}; The initializer_list goes out of scope right after and the ArrayRef will be left dangling. Just use a regular array uint64_t ar[2] = {a,b}; APInt ai(128,ar); The array should be implicitly converted to an ArrayRef at the call site. ~Craig On Wed, Apr 10, 2019 at 5:57 PM Peter McKinna via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Tim, > > Thanks for the hint. > > I tried the following, (it's a C interface since that's what I need it > for) where a and b are > the top and bottom halves of the 128 bit value, > > LLVMValueRef TestConst(LLVMContextRef C, uint64_t a, uint64_t b) { > Type *ty = Type::getFP128Ty(*unwrap(C)); > ArrayRef<uint64_t> ar[2] = {a,b}; > > APInt ai(128,*ar); > APFloat quad(APFloat::IEEEquad(), ai); > return wrap(ConstantFP::get(ty,quad)); > } > > but for 1.0e0 it returns zero > store fp128 0xL00000000000000000000000000000000, fp128* %e, align 16 > > and for 1.23e0 returns this, which is wrong. (that repeating 147AE is a > bit weird) > store fp128 0xLE147AE147AE147AE0000000000000000, fp128* %e, align 16 > > so I'm obviously doing something wrong. > > Regards Peter > > > > On Wed, Apr 10, 2019 at 9:44 PM Tim Northover <t.p.northover at gmail.com> > wrote: > >> Hi Peter, >> >> On Wed, 10 Apr 2019 at 08:01, Peter McKinna via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > Just wondering if it's possible to construct a 128 bit quad precision >> floating point >> > constant without converting the value back to a string. >> >> It looks like the constructor that takes an APInt treats it as a >> bag-of-bits representation according to IEEE float. It eventually ends >> up at https://llvm.org/docs/doxygen/APFloat_8cpp_source.html#l03098 as >> far as I can tell. >> >> Cheers. >> >> Tim. >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190410/84469dad/attachment.html>
Thanks Craig, Worked a treat. Regards Peter On Thu, Apr 11, 2019 at 11:05 AM Craig Topper <craig.topper at gmail.com> wrote:> This code line of code might not work correctly > > ArrayRef<uint64_t> ar[2] = {a,b}; > > The initializer_list goes out of scope right after and the ArrayRef will > be left dangling. > > Just use a regular array > > uint64_t ar[2] = {a,b}; > APInt ai(128,ar); > > The array should be implicitly converted to an ArrayRef at the call site. > > ~Craig > > > On Wed, Apr 10, 2019 at 5:57 PM Peter McKinna via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Tim, >> >> Thanks for the hint. >> >> I tried the following, (it's a C interface since that's what I need it >> for) where a and b are >> the top and bottom halves of the 128 bit value, >> >> LLVMValueRef TestConst(LLVMContextRef C, uint64_t a, uint64_t b) { >> Type *ty = Type::getFP128Ty(*unwrap(C)); >> ArrayRef<uint64_t> ar[2] = {a,b}; >> >> APInt ai(128,*ar); >> APFloat quad(APFloat::IEEEquad(), ai); >> return wrap(ConstantFP::get(ty,quad)); >> } >> >> but for 1.0e0 it returns zero >> store fp128 0xL00000000000000000000000000000000, fp128* %e, align 16 >> >> and for 1.23e0 returns this, which is wrong. (that repeating 147AE is a >> bit weird) >> store fp128 0xLE147AE147AE147AE0000000000000000, fp128* %e, align 16 >> >> so I'm obviously doing something wrong. >> >> Regards Peter >> >> >> >> On Wed, Apr 10, 2019 at 9:44 PM Tim Northover <t.p.northover at gmail.com> >> wrote: >> >>> Hi Peter, >>> >>> On Wed, 10 Apr 2019 at 08:01, Peter McKinna via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> > Just wondering if it's possible to construct a 128 bit quad >>> precision floating point >>> > constant without converting the value back to a string. >>> >>> It looks like the constructor that takes an APInt treats it as a >>> bag-of-bits representation according to IEEE float. It eventually ends >>> up at https://llvm.org/docs/doxygen/APFloat_8cpp_source.html#l03098 as >>> far as I can tell. >>> >>> Cheers. >>> >>> Tim. >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190411/e37f5713/attachment.html>