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>