[cfe-commits] [llvm-commits] [patch] fp128 sint_to_fp folding fix

[Tim Northover]

On Monday 07 Jan 2013 16:22:14 Renato Golin wrote:
> I thought as much... I don't know about others, but I feel that PPC should
> be the special case here, not IEEE. Though, it has nothing to do with your
> patch.

I've got some updated patches here that remove any default behaviour; as
Duncan pointed out it *is* largely inappropriate. The new interface is

    APFloat::APFloat(const fltSemantics&, const APInt&)

On the whole it turned out rather neatly. When needed, the fltSemantics were
usually easy to come by, even though there's a redundancy in APInt size and
semantics for the smaller cases.

I experimented with alternatives before settling on this (ignore names):

    APFloat::APFloat(const APInt&) // Faults if 128-bit attempted
    APFloat::getIEEEQuad(const APInt&)
    APFloat::getPPCDblDbl(const APInt&)

This seemed promising, but there were lots of places where code wanted to all
floating-point types, so some generic function was beneficial, and at that
point is it really worth adding a helper that only works for types < 64 bits.
You can bet someone will use it without thinking things through properly.

    APFloat::APFloat(const APInt&, enum { irrelevent, ieee128, ppc128 })

This was basically the same as the chosen variant, except that it introduced a
largely redundant enum.

I'm much less certain about the patch to Clang. What was there was clearly
wrong: AST serialisation didn't save the IsIEEE property, however there's no
existing good way to serialise an fltSemantics. Is there a better way I've
missed, or should I put the enum in a more standard place? There didn't seem
to be a directly equivalent construct.

Tim.

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apfloat-constructor-llvm.diff
Type: text/x-patch
Size: 31441 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130108/306a5249/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apfloat-constructor-clang.diff
Type: text/x-patch
Size: 5880 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130108/306a5249/attachment-0001.bin>