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

[Tim Northover]

Hi,

Ping? (Just to cfe list this time, LLVM consensus seems to be that it's the 
right thing to do).

Tim.
On Tuesday 08 Jan 2013 14:14:47 Tim Northover wrote:
> 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-clang.diff
Type: text/x-patch
Size: 5880 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130115/039dceb0/attachment.bin>