[LLVMdev] [RFC] Add a simple soft-float class

Sean Silva chisophugis at gmail.com
Wed Jun 18 13:08:31 PDT 2014


On Wed, Jun 18, 2014 at 12:02 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

>
> > On 2014 Jun 18, at 09:29, Sean Silva <chisophugis at gmail.com> wrote:
> >
> > Why not just use APFloat? (maybe even APInt would be sufficient for the
> desired semantics?)
>
> APFloat's API is awkward to use when doing math -- it's designed for
> compiling and optimizing code that uses floats, not for use as a simple
> number representation.
>
> It is possible to wrap APFloat though.
>
> > Is it purely a performance concern?
>
> Largely (assuming the other option is wrapping APFloat).
>
> Also, wrapping APFloat to give similar semantics is a fair bit a work.
>
> UnsignedFloat interoperates well with integers -- it's easy to compose out
> of (and decompose into) exponent and digit parts.  Again, this is API that
> could be added as a wrapper around APFloat.
>
> > Because it seems like you (and Andy) are supporting this as a suboptimal
> but convenient replacement for a proper integer-based representation.
>
> In a way, but I think of it as a suboptimal but safe replacement for
> hardware floats.  We currently use hardware floats as a suboptimal but
> convenient replacement for proper integer-based representations -- I'd like
> to swap in a soft-float instead.
>

Cool, this makes sense to me.

-- Sean Silva


>
> For some problems, proper integer-based representations are really hard,
> and can resemble a poor man's soft-float even when done right.
>
> > On the other hand, if it's just a performance optimization over
> APFloat/APInt, then this soft-float thing becomes quick hack + optimization
> which is a combination that gives me a pretty bad gut feeling (but may
> still be warranted, of course).
>
> It's a performance optimization over: a heavily wrapped APFloat to give it
> simple semantics.  Not sure if that gives you a better feeling...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140618/84309841/attachment.html>


More information about the llvm-dev mailing list