llvm dev - Apr 2019 - 128 bit float constant

Hi,

  Just wondering if it's possible to construct a 128 bit quad precision
floating point
constant without converting the value back to a string.

Cheers Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190410/a527f240/attachment.html>

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.

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>