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

[Owen Anderson]

On Jun 18, 2014, at 3:21 PM, Bruce Hoult <bruce at hoult.org> wrote:

> On Thu, Jun 19, 2014 at 10:08 AM, Owen Anderson <resistor at mac.com> wrote:
> 
> On Jun 18, 2014, at 3:05 PM, Bruce Hoult <bruce at hoult.org> wrote:
> 
>> On Thu, Jun 19, 2014 at 8:29 AM, Owen Anderson <resistor at mac.com> wrote:
>> Numerical analysis is hard.  Every numerics expert I have ever worked with considers trying to re-invent floating point a cardinal sin of numerical analysis.  Just don’t do it.  You will miss important considerations, and you will pay the price for it later.
>> 
>> I don't think anyone is planning to use it to write climate models. Or simulate airflow over a 787. Or even invert a near-singular matrix.
>> 
>> This is for jobs that *could* perfectly well be done with a simple integer with an implied scale factor, if you could easily and reliably predict in advance exactly what scale factor is appropriate for each value.
>> 
>> This simply keeps track of the scale factor for you, so you can't get it wrong.
> 
> If you couldn’t get it wrong, we wouldn’t have had so much difficulty getting the current version to work.
> 
> Non sequitur.
> 
> Statically analysing in advance the correct scale factor for all possible situations and values is super hard.
> 
> Given two actual values to be added/multiplied etc, determining the correct scale factor for that particular result is next to trivial.

I’m not advocating against using a floating point representation.  I understand that it’s valuable for this use case.  What I vehemently disagree with is the notion that we should design our own (approximation of) floating point.  It turns out that that’s really hard, even when you’re not simulating a 787.  It’s still important to be able to distinguish between the maximum value of your range and saturation.  It’s still valuable to be able to detect when an invariant of the numeric model was violated and you should just throw away the results.  It’s still valuable to avoid implicit bypassing of the rounded results so you don’t run into problems when values start to compound.

Making our existing soft float implementation (APFloat) more convenient and faster is a win-win.  It solves this particular use case without introducing risk of defining the representation wrong, AND it makes it easier and more convenient to use for other clients within the compiler.

—Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140618/2c55f7be/attachment.html>