[PATCH] D66050: Improve division estimation of floating points.

Mon Sep 2 07:14:34 PDT 2019

spatel requested changes to this revision.
spatel added a comment.
This revision now requires changes to proceed.

In D66050#1654733 <https://reviews.llvm.org/D66050#1654733>, @lebedev.ri wrote:

> In D66050#1624955 <https://reviews.llvm.org/D66050#1624955>, @nemanjai wrote:
>
> > 3. b) It might not be a bad idea to add a test to `test-suite` that will do some fast division vs. non-fast division to make sure the accuracy isn't too bad
> > 4. We should do some thorough analysis of the accuracy of the algorithm vs. the HW implementation on a wide range of values on a couple of targets (as was suggested above). I know this was done on PPC, so please share those results and try to replicate on another easily available target (such as X86).
>
>
> I think these two points weren't addressed.
>  I'd like to see at least some publicly-stated numbers on accuracy,
>  just so we //all// know this is going in the right direction for all inputs.

Changing my 'accepted' until this is answered.

The test at:
https://github.com/ecnelises/fp-division-test/
...seems to do a small random sampling.

The original transform was tested on x86 using brute force for all possible floats (1.0f/x) and is attached here:
https://bugs.llvm.org/show_bug.cgi?id=21385

I'm not sure how to prove this, but by distributing the multiplication into the last step of the estimate, I think we are always trading better accuracy around the numerator value with potentially overflowing to infinity for extremely different numerator/denominator. That's a good trade-off IMO and within the loosely-defined behavior enabled by 'arcp' in LLVM and '-mrecip' with Clang.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66050/new/

https://reviews.llvm.org/D66050